Document Link（文档链接）

基于提交 f33ec7b5a73ed335e7a2ca89f4490818cced4ecf，相关文档与代码：

• src/aicore/hcomm/common/hcomm_inner_def.h:41
• docs/zh/api/aicore/hcomm/WriteValueNbi.md:38
• docs/zh/programming_model/execution_model.md:156
• docs/zh/guide/hcomm_usage.md:143

Issues Section（问题文档片段）

1. odr=5 的执行序描述不一致

src/aicore/hcomm/common/hcomm_inner_def.h:41 将 odr=5 注释为 strongly ordered：

struct UrmaWqeEntry {
    uint32_t odr : 3;      // ordering, request ordering strength (0=unordered, 5=strongly ordered)
    uint32_t fence : 1;    // fence, 1=current WQE waits for all prior WQEs to complete
    uint32_t se : 1;       // solicited event, 1=trigger remote event notification on completion
    uint32_t cqe : 1;      // completion queue entry, 1=generate CQE on completion
    uint32_t inlineEn : 1; // inline enable, 1=data inlined in WQE instead of SGE reference

同一文件的默认配置：

static constexpr UrmaWqeEntry URMA_DEFAULT_CFG = {
    .odr = 5,
    .fence = 1,
    .se = 0,
    .cqe = 1,
    .inlineEn = 0,
};

static constexpr UrmaWqeEntry URMA_INLINE_CFG = {
    .odr = 5,
    .fence = 1,
    .se = 0,
    .cqe = 1,
    .inlineEn = 1,
};

但 docs/zh/api/aicore/hcomm/WriteValueNbi.md:38 对默认 URMA_INLINE_CFG 的说明为：

URMA WQE控制配置，默认URMA_INLINE_CFG（执行序为relax order + CQE保序上报 + 使能fence + 需要上报CQE + 携带inline数据）。立即数写要求inlineEn必须为1，否则编译报错。

相关编码证据：src/aicpu/asccomm/resource/connection/udma_data_struct.h:50：

struct UdmaSqe {
    uint32_t sqeBbIdx : 16;
    uint32_t placeOdr : 2;
    uint32_t compOrder : 1;
    uint32_t fence : 1;
    uint32_t se : 1;
    uint32_t cqe : 1;
    uint32_t inlineEn : 1;

src/aicpu/asccomm/resource/connection/ub_conn_lite.cc:28：

constexpr uint32_t UB_RELAX_ORDER = 0x1; // Relax Order表示当前SQE与后续Strong Order SQE有保序要求
constexpr uint32_t UB_STRONG_ORDER = 0x2; // Strong Order表示当前SQE有保序要求，该SQE不能超越前面的Relax Order SQE

AICore 路径 src/aicore/hcomm/impl/platform_v310/hcomm_aiv_urma.h:59 将 odr 的三位直接填入 SQE flag：

    sqeCtx->flag = (config.odr & 0x7U) | ((config.fence & 0x1U) << 3U) | ((config.se & 0x1U) << 4U) |
                   ((config.cqe & 0x1U) << 5U) | ((config.inlineEn & 0x1U) << 6U) |
                   (opCode == HcommUrmaOpCode::WRITE_WITH_REDUCE ? HCOMM_URMA_UDF_FLAG : 0U);

结合上述位布局，推导 odr = placeOdr | (compOrder << 2)，则 5 (0b101) 对应 Relax Order + CQE保序，6 (0b110) 对应 Strong Order + CQE保序。这是基于仓内实现的推导，请维护者确认是否适用于该 AICore URMA 路径。

2. Fence 等待范围描述不一致

src/aicore/hcomm/common/hcomm_inner_def.h:43：

    uint32_t fence : 1;    // fence, 1=current WQE waits for all prior WQEs to complete

而 docs/zh/programming_model/execution_model.md:181：

Fence标志启用时，必须等待前面的读操作或原子操作完成后才能执行，可与Order标志配合使用。

两者分别描述为“所有前序 WQE”和“前序读或原子操作”，对前序 Write 是否在等待范围内的口径不同。

Existing Issues（存在的问题）

以上差异影响开发者判断后续事务与前序 Write/Read/Atomic 的依赖关系，以及仅等待末任务 CQE 是否足以确认整批完成。

docs/zh/guide/hcomm_usage.md:145 明确提出以下前提：

在顺序和fence配置能够保证最后一个任务在之前任务之后完成时，可以只为最后一个任务设置cqe = 1，再通过批量Drain确认整批任务完成。

希望维护者澄清并统一相关注释及中英文文档：

1. odr 各编码对应的执行序和完成序，特别是 odr=5 与 odr=6。
2. Fence 是否等待前序 Write，还是仅等待 Read/Atomic；是否存在操作类型或平台限制。
3. 仅等待末任务 CQE 确认整批完成所需的配置与作用范围，包括同一 SQ 内不同 peer/TP 的情况。

本 issue 反馈仓内说明不一致，尚未据此认定硬件行为或通信实现存在缺陷。