1. Separate Capacity from Host Address Reachability
Start with the complete manufacturer code and the flash item used by the released design. Record the device family and the design reference that identifies it. Keep the memory's capacity description alongside that identity, while asking the firmware owner to describe which regions must be accessed. A larger capacity entry is not a record of how the host reaches those regions.
Separate the stages involved in the requirement. The initial boot mechanism, a later bootloader, application firmware and a production programmer can have different documented capabilities or configuration responsibilities. List only the stages that actually apply to the customer's system. Do not assume that a function available in later software is also available when the first boot data is requested.
For each stage, retain the relevant command-format and address-state evidence supplied by its owner. Identify whether the requirement refers to a released firmware version, a documented programmer configuration or an unresolved assumption. This creates a specific reachability question: which required region can the identified stage address under the state present at that point? It supplies no answer about an unidentified customer's hardware.
2. Read the Family Address-State Mechanism
Infineon's FL-S datasheet describes a Bank Address Register and an EXTADD field affecting the address expected by legacy commands. The written explanation links the bank-address contribution and the extended address-field state. Use this as a family-specific reason to preserve the mechanism, rather than reducing the request to capacity or transferring a command convention from another serial-memory family.
Keep the manufacturer's description of the requested state with the exact family reference. Record separately what the host documentation says it sends and what device state that description expects. A phrase such as extended addressing can conceal a difference in the underlying mechanism. Ask the reviewer to resolve the actual documented relationship before a candidate is treated as satisfying the released requirement.
Describe a proposed memory under its own documentation instead of relabelling it with the incumbent's protocol description. Where command or state evidence is incomplete, mark the affected boot stage as unresolved. Preserve the original requirement while engineering investigates the difference. This comparison deliberately stays at the documented mechanism level; it provides no opcode list, register-writing procedure or claimed successful programmer configuration.
3. Keep Reset Default and Startup Access Separate
The same FL-S description identifies EXTADD as volatile and states that it is cleared by default after power-up, hardware and software resets. That matters when the expected address state was established earlier in operation. Keep the particular reset context visible in the review. The fact that a configuration was known during one stage does not document the state used after a later reset.
Create a state-handover record showing the stage, its expected address context and the existing evidence for that expectation. Record who maintains any necessary configuration and what release document covers the transition. Leave unknown reset handling open. Such a record helps firmware and purchasing discuss the same requirement without inventing a command sequence or claiming that the offered device has been exercised through it.
Startup access is a separate question. FL-S section on power-up includes a supply and access-delay context before instructions can be used. Retain that reference alongside the reset-state information, asking the system owner to identify its applicable startup evidence. Address-format documentation alone cannot settle the startup review. This article gives no timing value, power-sequence calculation or board-level reset result.
4. Record the Unresolved Host Evidence
Bring the device mechanism and host-stage records together in a review specific to the requested memory. Include the exact family, required regions, each applicable boot or programming stage and the documentation covering its address expectations. Keep missing host references identifiable instead of completing the comparison from a memory marketing description. The design owner determines whether the available material supports its intended requirement.
Distinguish a proposal from the released procurement item. If a different flash or a changed addressing requirement is under consideration, retain the relevant engineering decision before replacing the confirmed ordering code. A supplier's description of a memory option cannot document changes to customer boot firmware. Preserve unresolved questions about the host, concrete commands or exact ordering variant for their responsible owners.
For an ICULTRA sourcing inquiry, provide the permitted flash identity and the accepted addressing requirement, with a short stage-specific exception list where support remains unresolved. Link the relevant manufacturer and customer-owned references when they can be shared. This makes the memory question reviewable while keeping the actual boot decision with its owner. Availability and supply terms still require separate confirmation for the exact requested item.
Sources and further reading
Infineon FL-S documentation supports the family-specific address-state, reset-default and startup distinctions. The host-stage record is a preparation suggestion; no command recipe, timing calculation or bootloader compatibility result is supplied.