repo-test-develop

Decompose each input and attribute into orthogonal factors like dtype, shape, format, and value range, then apply single-factor coverage for L0, pairwise combination for L1, and one case per anomaly scenario for L2. Include boundary shapes, non-aligned tails, and special values like inf and nan.

Mode B means no evaluation suite exists, so you self-build the golden, cases, and run.sh harness. Mode A means an evaluation suite provides golden, cases, and operator prototypes, so your job is aligning to its contract, checking case coverage, and adding white-box cases only.

Enumerate all live branches from the kernel Process control flow and host tiling code, such as tail blocks, non-aligned DataCopyPad, multi-core boundaries, and tilingkey dispatches. Then reverse-solve shapes and dtypes that trigger each branch, and record a branch coverage report.

Default standards are rtol/atol of 1e-5 for FP32, 1e-3 for FP16, and 1e-2 for BF16, with authoritative values taken from the ops-precision-standard skill. In Mode A, the evaluation framework's own judgment criteria are the final arbiter and override self-built tolerances.

Because the device quantizes or truncates inputs, the golden must apply identical processing to the same data, such as rounding then clamping integers or rounding each operand to fp16/bf16 before computing. Otherwise precision comparisons produce false mismatches.

Use it when the operator has many parameters, complex dependencies or broadcasting, and you need an auditable coverage report. For simple elementwise operators, manual factor-based design following the documented steps is lighter and sufficient.