1. Define the Logic Function Needed During Startup
Begin with the task that must be available early in the system's startup. It may be a defined control relationship or an interface function in the released design. Describe the required behaviour and the condition under which it is needed. A request for nonvolatile logic becomes more useful when it identifies that task, rather than relying on a general startup label.
Locate the function within the system's startup dependencies. Ask what other circuitry or control information the application expects to be available when that function is required. Preserve those expectations as engineering requirements, without assigning a delay or inventing a power sequence. The resulting question concerns when the required logic becomes usable in the application, not simply whether a device has nonvolatile storage.
Separate the requirement from a claim that it has been met. An existing design release may already identify the accepted device and its startup assessment. A proposed alternative needs its own review against the same early-control requirement. The availability of a family feature description helps frame that review, but does not establish that another device or an unexamined board behaves the same way.
2. Distinguish Configuration Flash from User Flash
Lattice's MachXO2 family information lists configuration memory as internal flash and identifies user flash memory separately. Retain that separation when comparing the required resources. Storage associated with defining the logic configuration and storage described for user information are different entries in the manufacturer's presentation. A general flash-capacity description cannot tell purchasing which of those resources a requirement actually concerns.
Ask whether the requested memory feature relates to the device's configuration or to information the application needs to retain. State the applicable resource by the manufacturer's terminology. This avoids using a user-memory description as evidence for the configuration source, or treating configuration storage as though it independently answers an application-data requirement. No capacity calculation or access method is supplied by this distinction.
Keep the requested family and exact ordering identity with the resource description. A table describing MachXO2 is evidence about that family within its stated scope. It is not a universal resource map for every CPLD or programmable-logic product. When another candidate uses different terminology, obtain its own configuration and user-storage descriptions before treating the resource fields as equivalent purchasing requirements.
3. Read Instant-On and Dual-Boot Claims in Context
The MachXO2 information describes instant-on logic in the context of controlling signals during system power-up. Use that wording as a qualitative feature reference. It does not supply the application's complete readiness condition. The actual early-control task still has its own dependencies, design context and acceptance criteria. An instant-on label should not be rewritten as a promise of zero delay in the customer's system.
The same family information includes a footnote stating that dual boot is supported with external boot flash. Preserve that condition when discussing the feature. Internal configuration flash and the external-flash condition for a documented dual-boot arrangement are not contradictory descriptions of one undifferentiated memory requirement. They refer to different aspects of the family's configuration and startup offering.
A blanket statement that nonvolatile logic removes every external-memory review would discard that footnote. Ask whether the application relies on the documented dual-boot feature and what configuration arrangement its released design specifies. Keep any missing startup or boot-source evidence open. This guide does not interpret an initialization diagram, prescribe a loading sequence or identify a toolchain that has been qualified for the application.
4. Keep Configuration Approval with the Startup Requirement
Consider a control function that the application needs before another system element is ready. The useful selection question is whether the proposed logic and configuration arrangement can support that required function in its stated startup context. Merely finding internal flash in a feature table does not answer the dependency question. Keep the actual early-control requirement in view when comparing nonvolatile devices.
Link the selected device to the application's authorised configuration reference where one is required. The reference identifies the intended design deliverable; it should remain distinct from the semiconductor ordering code. A manufacturer's family overview does not verify a customer's configuration, its release status or its relationship to a proposed hardware change. Those decisions need the responsible design team's accepted evidence.
For procurement, retain the exact device identity and the early-control function that selection must support. Add separate configuration-memory, user-memory and applicable dual-boot requirements, with the source references used for each. A proposed replacement remains a proposal until engineering resolves its dependencies. No bitstream interchangeability, programming procedure, startup-time value or completed board-level result is established by this qualitative comparison.
Sources and further reading
Lattice's MachXO2 family page supports the separate configuration/user-flash fields, qualitative instant-on context and external-flash dual-boot footnote. No startup-time calculation, initialization sequence, toolchain or bitstream compatibility is claimed.