docs: list Ascend-FFT as a cross-platform migration

README.md

@@ -31,7 +31,9 @@ deferrals, baseline coverage and the distinction from historical v0.8 results.
    then the [Programming Guide](docs/programming_guide.md) and [C Plan API](docs/c_api.md).
 3. **Understand the method:** read [Design Overview](docs/design_overview.md),
    [Hardware Mapping Methodology](docs/hardware_mapping_methodology.md), and
-   [v0.8 Nested Physical Space](docs/v0.8_nested_physical_space.md).
+   [v0.8 Nested Physical Space](docs/v0.8_nested_physical_space.md). The
+   [cross-platform ports](docs/platform_ports.md) page shows how the method is
+   independently lowered to non-CUDA hardware.
 4. **Understand the design space:** read [Architecture Guardrails](docs/architecture_guardrails.md),
    [Processing-Unit Design Space](docs/processing_unit_design_space.md), and
    [Runtime Selector](docs/runtime_selector.md).
@@ -207,6 +209,9 @@ The most important architecture documents are [Design Overview](docs/design_over
 [Hardware Mapping Methodology](docs/hardware_mapping_methodology.md),
 [v0.8 Nested Physical Space](docs/v0.8_nested_physical_space.md), and
 [Processing-Unit Design Space](docs/processing_unit_design_space.md).
+The [cross-platform migration list](docs/platform_ports.md) currently includes
+[Ascend-FFT](https://github.com/TruNcat3/ascend-fft), an independent lowering of
+the method to Huawei Ascend AIV/UB/MTE rather than a reuse of CUDA kernels.
 
 ## Evidence And Scope
 

docs/README.md

@@ -98,6 +98,7 @@ The following is an optional first-time orientation, not a prerequisite for edit
 | What must an implementation preserve? | [Architecture Guardrails](architecture_guardrails.md) |
 | How does APPT-style online layout fit the architecture? | [APPT Static Layout](appt_static_layout.md) |
 | How does cuButterfly relate to prior work and libraries? | [Research Positioning](cubutterfly_positioning.md), [FFT Library Comparison](fft_library_comparison.md) |
+| Where has the method been migrated to another platform? | [Cross-Platform Ports](platform_ports.md) |
 
 ## Reproduce The Evidence
 

docs/design_overview.md

@@ -34,6 +34,11 @@ operators at the same length may use different cores as well. Cross-GPU
 deployment requires a new capability/calibration table; a point validated on
 V100 is not silently reused as an optimum on another GPU.
 
+The [cross-platform ports](platform_ports.md) page records concrete migrations
+under this contract. In particular, Ascend-FFT preserves the mapping method but
+rebuilds the realization around AIV, UB, MTE, and GM; it is not a CUDA-kernel
+translation and does not inherit CUDA performance results.
+
 The separation is represented by seven objects:
 
 ```text

docs/platform_ports.md

@@ -0,0 +1,50 @@
+# Cross-Platform Ports
+
+cuButterfly's portable object is the **mapping method**, not a CUDA binary or
+a fixed kernel configuration. A cross-platform port should preserve the
+stage/data space-time decomposition and rebuild its hardware lowering,
+processing units, legality rules, and measured selection data for the target.
+
+## Migration Instances
+
+| Target | Project | Status | Architecture mapping | Evidence boundary |
+|:--|:--|:--|:--|:--|
+| NVIDIA CUDA | [cuButterfly](https://github.com/TruNcat3/cuButterfly) | Reference implementation | lanes/warps/CTAs, registers/shared memory, shuffle/global transport | V100 is the frozen v0.8 baseline; other GPUs require target-local calibration |
+| Huawei Ascend | [Ascend-FFT](https://github.com/TruNcat3/ascend-fft) | Independent FFT port | AIV execution, UB residence, MTE transport, and GM boundaries | Ascend910_9382 C2C/R2C/C2R fp32 results; see that repository's published protocol and snapshot |
+
+Ascend-FFT reuses the architecture vocabulary and search methodology. It does
+not reuse cuButterfly CUDA kernels, and its measurements are not evidence for
+CUDA performance. Conversely, cuButterfly's V100/A100 configurations are not
+valid Ascend tuning tables.
+
+## Port Acceptance Contract
+
+A project is a method-level migration instance when it documents all of the
+following:
+
+1. The stage and data dimensions expose independent space/time factors, such
+   as `(Us, Ts, Ud, Td)`, rather than one fixed tile recipe.
+2. Hardware facts and resource limits are measured on the target, and illegal
+   mappings are rejected before performance ranking.
+3. Processing-unit selection is separate from architecture mapping, with an
+   explicit lowering contract for each supported core.
+4. Residence, boundary layout, synchronization, ownership, and materialized
+   off-chip traffic are reported as physical realization properties.
+5. Model-ranked candidates are validated by target-local correctness and
+   timing measurements; results identify hardware and benchmark protocol.
+
+This list is intentionally stricter than “implements an FFT.” It lets readers
+distinguish a port of the architecture method from an unrelated implementation
+or a direct translation of one CUDA kernel.
+
+## Adding A Port
+
+Open a documentation change that adds one row to the table and links to:
+
+- the target repository and license;
+- its architecture/lowering explanation;
+- its supported operators and numeric contracts;
+- a reproducible, target-local benchmark protocol;
+- the cuButterfly citation or provenance statement used by the port.
+
+Performance claims remain local to each project and hardware target.