NVM 知識決策工作台 · 公開版 NVM KNOWLEDGE WORKBENCH · PUBLIC EDITION

從 NVM 物理技術 From NVM technology
到可辯護的架構決策 to a defensible selection

針對半導體技術白皮書、持久狀態契約權衡與企業內容模型所構建的受治理工作台——圍繞著何種技術可被支援、何種指標必須驗證、以及何種邊界仍待探索。 A governed workspace for technology whitepapers, state-contract trade-offs and enterprise content models—built around what can be supported, what must be validated and what remains open.

公開工作草案PUBLIC WORKING DRAFT 展示設定檔僅作為架構決策輔助,非商業產品保證規格。 Illustrative profiles are decision aids, not product specifications.

Conceptual NVM state-contract map Four persistent-state contracts connect through an evidence boundary to an NVM selection core. IMMUTABLEIDENTITYprogram once · verify always BOUNDEDCALIBRATIONrare updates · controlled owner ADAPTIVEFIRMWAREmanaged change · recovery path OPERATIONALRAS STATElogs · repair · field learning NVM SELECTIONSTATECONTRACT EVIDENCE · SCOPE · LIMIT
概念性 NVM 狀態契約地圖 · 非物理佈局圖 Conceptual NVM state-contract map · not a physical floorplan

探索決策工作台 EXPLORE THE WORKBENCH

每一種檢視皆完整保留技術證據狀態與架構契約。 Each view preserves evidence status and a rigorous architecture contract.

01 · NVM OVERVIEW

NVM is a system state decision,
not a product-name decision

Start with the state the system must preserve. Then constrain technology by ownership, update cadence, process options and evidence.

01

Program once; verify throughout life

Immutable identity

Device identity, lifecycle state and boot trust anchors
OWNER
Provisioning authority
DECISION QUESTION
Can the state ever be rotated, revoked or recovered?

LIMITThreat model and provisioning flow must be explicit before selecting OTP.

02

Rare, controlled updates

Bounded calibration

Trim, remap, analog compensation and configuration
OWNER
Manufacturing or hardware controller
DECISION QUESTION
How many updates are required after test, package and field aging?

LIMITEndurance, write energy and high-voltage availability are use-case specific.

03

Managed change with rollback or recovery

Adaptive firmware

Boot code, patches, policy and feature configuration
OWNER
Secure update service
DECISION QUESTION
Does capacity and update frequency justify an embedded array?

LIMITSeparate code-storage needs from immutable security state.

04

Repeated writes over system life

Operational evidence

Repair history, RAS logs, counters and field learning
OWNER
Platform controller
DECISION QUESTION
Which state must survive power loss, service events or module replacement?

LIMITSystem retention and recovery may be more important than bit-cell density.

01

Architecture baseline

OTP

One-time physical state transition
STRONGEST FIT

Immutable and monotonic state

PROCESS LENS

Broad logic-node reach; implementation is provider specific

BOUNDARY

A written bit cannot become an update policy by itself

02

Public evidence needed per process

Embedded MTP IP

Reprogrammable on-chip state; may use EEPROM storage
STRONGEST FIT

Bounded calibration and small firmware state

PROCESS LENS

EEPROM-based IP depends on high-voltage and oxide options

BOUNDARY

An embedded macro, distinct from external standalone EEPROM; endurance, programming supply and retention need joint qualification

03

Node-specific decision

Embedded Flash

Dedicated embedded charge-storage integration
STRONGEST FIT

Code-rich embedded systems

PROCESS LENS

Commercial fit is shaped by mask cost and process-development complexity

BOUNDARY

Node migration is an economics and integration decision—not a simple shrink

04

Evidence varies by platform

MRAM / ReRAM

Magnetic or resistive state
STRONGEST FIT

Advanced-node embedded NVM where available

PROCESS LENS

Foundry module, density and qualification status dominate

BOUNDARY

Availability does not automatically establish application readiness

05

Companion architecture

SRAM PUF + crypto

Power-up-derived secret plus cryptographic protection
STRONGEST FIT

Companion security layer above persistent ciphertext

PROCESS LENS

System architecture rather than a peer storage medium

BOUNDARY

Reliability, helper data and attack assurance still require validation

MATURE & SPECIALTY

Start with the available voltage and device stack

For power, BCD, sensor and interface products, I/O devices and programming-voltage generation often define the feasible NVM set before density does.Validate I/O voltage, charge pump, test flow and retention together.

eFLASH TRANSITION

Treat scaling as an integration-economics boundary

Conventional embedded-flash commercialization is widely associated with the 28 nm generation. Crossing that boundary is not a hard physics cliff; mask count, development effort and manufacturing economics shape adoption.Keep vendor-specific mask-stack detail in the internal evidence layer.

ADVANCED NODE

Decouple read supply from program infrastructure

A single-VDD read path can simplify always-on and low-voltage domains, while programming may still require an I/O-derived foundation for an internal charge pump.Specify read and program power contracts separately.

LEADING EDGE & CHIPLET

Move from one macro to a distributed state architecture

Identity, repair, calibration, firmware and operational logs may reside in different dies or controllers. The selection unit becomes the system state contract, not a single NVM array.Define ownership, trust boundary and recovery before technology.
  1. 01
    Name the state

    What survives power loss—and why?

  2. 02
    Assign ownership

    Who may create, update, revoke or recover it?

  3. 03
    Constrain the process

    Which node, voltage and integration options actually exist?

  4. 04
    Close the evidence gap

    What is sourced, inferred or still target-silicon dependent?

Apply the sequence in the Decision Matrix