Memory Technology

ECC and Non-ECC Memory in Industrial Platforms

Error correction at module level requires both a module that carries the additional device width and a platform that supports it. This note describes the distinction between module-level ECC and error handling implemented inside the memory device.

Updated 2026-08

Engineering Context

Module-level ECC adds a data path beyond the 64-bit organization used by a standard non-ECC module, so that the memory controller can detect and correct certain errors as data is read. It is a property of the module and the controller together: an ECC module in a platform without ECC support does not provide correction.

Error handling implemented inside a memory device is a different mechanism with a different scope. Where a generation defines such a feature, it operates within the device and does not by itself make a module an ECC module.

Terminology

Module-level ECC compared with device-level error handling
ItemModule-level ECCDevice-level error handling
ScopeData transferred between module and controllerInternal to the memory device
Platform supportRequiredNot applicable at platform level
Module organizationAdditional device width beyond 64-bitNo change to module organization
Product statementPublished as an ECC moduleDoes not make a module an ECC module

Selection Considerations

  • Controller support. ECC operation depends on the memory controller and the platform configuration; support should be confirmed before an ECC module is specified.
  • Module availability. ECC and non-ECC modules are separate products with separate part numbers, capacities and qualification records.
  • Application requirement. The decision is normally driven by the consequence of an uncorrected error in the application rather than by generation.
  • Product documentation. Whether a specific module is ECC or non-ECC is stated in its product documentation and should be read from there rather than inferred from the generation.

Bus Width and Module Organization

A standard non-ECC module presents a 64-bit data path to the controller. A module-level ECC configuration adds device width beyond that path so the controller can transfer check information alongside the data.

The additional width is visible in the module organization and in the part number, which is why ECC and non-ECC modules are ordered as separate products rather than as options against the same configuration.

Qualification and Availability

Because they are separate products, ECC and non-ECC configurations carry separate qualification records and separate availability. A platform qualified with a non-ECC configuration is not automatically qualified with the ECC equivalent, even at the same capacity and data rate.

Where a programme may adopt ECC later, it is worth confirming platform support and product availability during the initial configuration review rather than at the point of transition.

Application Guidance

  • Consequence of an uncorrected error. Applications differ in how an undetected data error propagates; this is normally the primary consideration.
  • Platform support. Controller and firmware support determines whether correction is actually active, regardless of the module installed.
  • Configuration record. The ECC status of the qualified configuration should be stated in the project record so that replacement material is ordered correctly.

Where Module-Level ECC Is Commonly Specified

Module-level ECC is normally specified where an undetected data error would propagate into a result that is difficult to identify afterwards: extended unattended operation, long computation runs, or systems whose output is used by another process without further checking.

It is less commonly specified where the application already validates its own data, or where a fault is immediately visible and the unit can be restarted without consequence.

Reporting and Visibility

Correction is only useful operationally if corrected events are visible. Whether corrected errors are logged, and where that log can be read, depends on the platform rather than on the module.

For programmes that intend to monitor memory health in the field, this should be confirmed during platform review, alongside the module selection itself.

Reviewing an Existing Platform

For an installed platform the question is usually whether ECC can be introduced without other changes. That depends on controller support, the memory configuration the board expects and whether an ECC configuration exists at the required capacity and data rate.

If those conditions are met, the change is still a configuration change and is qualified as such. If they are not, introducing module-level correction becomes a platform decision rather than a memory selection, and is normally addressed at the next platform generation.

Engineering Summary

ECC is a platform-level capability that requires a matching module and controller. Device-level error handling is a separate mechanism and should not be described as module ECC. Where an application requires module-level correction, both the platform support and the module part number should be confirmed during configuration review.

Related SIMORCHIP Resources

Project Enquiries

Provide the target platform, required memory or storage configuration, operating conditions and expected programme lifecycle. SIMORCHIP engineering will review the applicable product configuration and qualification scope.