Internal Wiki

主题

跟踪载荷：UHI / OCI / ICI / DMA 频带 ​

本页所有地址和偏移都适用于 libtpu-0.0.40-cp314 wheel 中的 libtpu.so（build-id 89edbbe81c5b328a958fe628a9f2207d）。该二进制文件未剥离符号，包含完整 C++ 符号，且 .text VMA 等于文件偏移。其他版本会有所不同。

摘要 ​

本页给出片上 TPU profiler 捕获的高价值设备事件频带的逐跟踪点载荷位解码：UHI（host↔chip DMA）、OCI（片上/片外互连描述符、消息和读写命令）、ICI（芯片间链路包）、片内 DMA 频带（pufferfish 上为 CMQ VPU-DMA，ghostlite 上为 CMN-DMA）、TCS sync-flag 原语（set/add/read/wait/fence），以及 throttle/stall 事件。每个 Decode<Name>(string_view, bool* started_out, TraceEntry* out) 都是可从各 family 的 DecodeEntry 跳转表到达的匿名命名空间函数；每个事件的载荷都是固定的 GetBits64 调用序列，本页按频带列出每个 宽度 → 字段名 → 含义 的映射。

帧结构由其他页面负责，此处不重复。通用外壳，也就是固定的 16 字节（128 位）包、2 位 valid/started 帧前缀、59 位 TraceHeader（trace_point_id:8 · block_id:3│6 · timestamp:48│45）、可选的 36/38 位 TraceIdHeader、解码/编码双派发，以及每事件总位数 CHECK，是 TraceEntriesCoder 的主题。请先阅读该页：下面每个宽度序列都从通用 SkipBits(2) + DecodeTraceHeader 之后开始，因此载荷总是从包 bit 61 开始；列出的 CHECK 常量是包含这 61 位在内的总消耗位数（载荷位数 = CHECK − 61）。id→name 注册表由 TracePoints 主注册表 负责；本页解码这些 id 所命名的载荷。

最重要的阅读规则：宽度序列写作 TIDhdr | payload。当事件携带身份信息时，开头的 21,3,12（pxc）或 21,3,14（glc/gfc）就是 TraceIdHeader{transaction_id, core_id, chip_id}；| 将其与带类型的载荷标量分开。宽于 32 位的多位值由 BitDecoder 从多个 GetBits64 片段重新组装（例如 30,…,29 这一对会送入一个 64 位目标），这就是为什么载荷宽度列表中会出现看似奇怪的片段宽度，并与 1 位 bool 标志交错。

对于重新实现，本页补全的契约是：

  • 逐跟踪点载荷字段映射：六个频带中每个事件的有序 GetBits64 宽度序列、每个宽度写入的命名 proto 字段，以及总位数 CHECK。
  • OCI 频带的形状共享结构：三个重复出现的载荷形状（A/B/C）驱动 99 个 pxc 事件中的约 30 个；应学习这三个形状，而不是三十个事件。
  • 各代宽度漂移：chip_id 和 dst_chip_id 从 12 位扩展到 14 位，virtual_channel 从 3 位收窄到 2 位，sync-flag 载荷增加一个 64 位 lcc 字段，pxc→glc。
  • 多包规则：CHECK > 128 的事件跨越两个 16 字节包；bytes-consumed 是 0x20（32），不是 0x10。
频带pxc trace_point_id事件携带 TraceIdHeader置信度
UHI host-DMA0–67是（21,3,12）CERTAIN（pxc）
OCI 描述符 / 消息 / 命令7–10, 20–27, 49–55, 91–96, 141~30是CERTAIN（pxc）
ICI 链路包40–489是CERTAIN（pxc）
片内 DMA（CMQ VPU-DMA）140–14910是CERTAIN（pxc）
TCS sync-flag80–9011仅 id 80CERTAIN（pxc）
Throttle / stall971（双变体）否CERTAIN（pxc）
BarnaCore FSM（共享 throttle 字）100–11920否HIGH
pxc 已解码总计0–149, 25599混合CERTAIN
各代后继（glc）HDE 8–13, CMN-DMA 72–79, cycle-skip 200–218抽样是（21,3,14）HIGH（glc）/ SAMPLED（vfc/vlc/gfc）

读取载荷行 ​

下面频带表中的每一行都是一个 Decode<Name> 的字节精确输出。列是统一的：

text
id  EVENT  oneof=F  CHECK=bits(pkts)  widths = [TIDhdr | payload scalars]
```text

- **`id`**：线上的 8 位 `trace_point_id`（解码派发键）。
- **`oneof`**：写入 `TraceEntry+0x28` 的密集 proto2 oneof 字段号（编码派发键）。两个 id 空间不同；见 [TraceEntriesCoder §双派发](trace-entries-coder.md#the-dual-dispatch)。
- **`CHECK`**：每事件 `CHECK` 验证的硬编码总位数常量（`cmp $CONST,%rdi; jne FATAL`）。载荷位数 = `CHECK − 61`。
- **`pkts`**：当 `CHECK ≤ 128` 时为 `1`（一个 16 字节包，bytes-consumed `0x10`），当 `128 < CHECK ≤ 256` 时为 `2`（两个包，bytes-consumed `0x20`）。
- **`widths`**：按流顺序排列的 `GetBits64` 宽度立即数。`|` 之前的前导 `21,3,12`（pxc）或 `21,3,14`（glc）是 `TraceIdHeader`；之后的标量是带类型的载荷。

`CHECK` 验证的已消耗位数在每个解码器中都以相同方式计算：

```c
// universal consumed-bit guard, byte-confirmed in every Decode<Name>
consumed = (end_ptr - buffer_start_ptr) * 8 - bits_remaining;   // BitsDecoded()
if (consumed != CHECK)                                          // cmp $CONST,%rdi
    MakeCheckOpString(consumed, CHECK, "decoder.BitsDecoded() == K");  // FATAL
bytes_consumed = (CHECK <= 128) ? 0x10 : 0x20;                 // movq $bytes,0x8(%rbx)

陷阱 — 宽度片段并不全都是独立的 proto 字段。宽于 32 位的字段（dpa_upper_bits、address、dva、src_operand、lcc）会通过多个 GetBits64 调用读取，其结果被移位/OR 到 TraceEntry+0xNN 的单个 64 位目标槽中。把一个宽度映射为一个字段的重新实现会多计字段设置。宽片段之间交错的 1 位宽度才是真正的 bool 标志（is_l2_pte_fetch、done、multicast 等），这些确实各自对应一个字段。精确的逐片段 shift/OR 顺序只对命名频带做过追踪（对精确重组位位置置信度 LOW；但宽度和目标为 CERTAIN）。

UHI — Unified Host Interface Host-DMA（pxc ids 0–6） ​

pufferfish 上的 host↔chip memory-DMA 频带：地址转换、物理读/写请求及其响应，以及经 OCI 桥接的变体。每个 UHI 事件都携带 TraceIdHeader{transaction_id 21, core_id 3, chip_id 12} = 36 位，因此其载荷从包 bit 61 + 36 = 97 开始。

载荷字段映射 ​

id事件oneofCHECKpkts宽度（TIDhdr | payload）置信度
0UHI_HOST_DMA_TRANSACTION_STARTED_ADDRESS_TRANSLATION2216221,3,12 | 5,16,10,1,1,54,32CERTAIN
1UHI_HOST_PHYSICAL_REQUEST_READ3233221,3,12 | 1,30,1,1,29,26,8,20,20CERTAIN
2UHI_HOST_PHYSICAL_RESPONSE_READ4118121,3,12 | 1,20CERTAIN
3UHI_HOST_PHYSICAL_REQUEST_WRITE5233221,3,12 | 1,30,1,1,29,26,8,20,20CERTAIN
4UHI_HOST_PHYSICAL_RESPONSE_WRITE6118121,3,12 | 1,20CERTAIN
5UHI_OCI_REQUEST_READ7165221,3,12 | 31,1,1,19,14,1,1CERTAIN
6UHI_OCI_REQUEST_WRITE8165221,3,12 | 31,1,1,19,14,1,1CERTAIN

命名字段 ​

命名 proto 字段来自 trace_entries.proto 中的 UhiHostPhysicalRequestRead 及其兄弟消息：

  • id 0 queue_id（enum，5）· sequence_number（uint32，16+10 拆分）· dva（uint64，1,1,54 片段）· size（uint32，32）。最宽的 UHI 事件，需要两个包来承载 54 位设备虚拟地址和 32 位大小。
  • id 1 / id 3 is_l2_pte_fetch（bool，1）· dpa_upper_bits（uint64 @ +0x20，30+29 片段）· dva_middle_bits（uint32 @ +0x2c，26）· size_units_of_32B（uint32 @ +0x30，8）· num_chunks（uint32 @ +0x34，20）· chunk_id（uint32 @ +0x38，20）。读请求和写请求字节相同，并共享一个 Encode 处理器（0xf5c5e91）。
  • id 2 / id 4 响应 ack：一个标志（1）+ 一个 20 位 id/sequence。最小的 UHI 事件，一个包。读响应和写响应共享 Encode 0xf5c6029。
  • id 5 / id 6 经 OCI 桥接的请求：f_on_chip_byte_address（uint64，31 + 片段）· id（uint32，19）· write_data_type_is_instruction（bool，1）· write_is_ordered（bool，1）。

说明 — 读/写配对（id 1↔3、2↔4、5↔6）是结构性的：每一对都有相同线格式，只由 trace_point_id 区分。解码产生相同的宽度序列；编码把两个 oneof 字段折叠到一个处理器上。重新实现可以像二进制文件一样，把每一对建模为一个带方向标签的 codec。

各代后继 — HDE（Host DMA Engine），glc ids 8–13 ​

在较新的 family 上，UHI 频带被 HDE 取代。因为 chip_id 从 12 位增长到 14 位，TraceIdHeader 扩展为 21,3,14（= 38 位），载荷基址变为 bit 61 + 38 = 99。

glc id事件oneofCHECKpkts宽度（21,3,14 | payload）置信度
10HDE_HOST_REQUEST_WRITE10178221,3,14 | 3,26,1,1,33,5,10HIGH
11HDE_HOST_RESPONSE_WRITE11112121,3,14 | 3,10HIGH
12HDE_HOST_REQUEST_READ12178221,3,14 | 3,26,1,1,33,5,10HIGH
13HDE_HOST_RESPONSE_READ13112121,3,14 | 3,10HIGH

HDE 请求字段：thread_id（enum，3）· address（uint64，26+1+1+33 片段）· size_units_of_32B（uint32，5）· thread_tracking_id（uint32，10）。响应只携带 thread_id（3）+ thread_tracking_id（10）。解码器锚点：DecodeHdeHostRequestRead @ 0xf62e660，DecodeHdeHostResponseRead @ 0xf62ea20。

OCI — 描述符 / 消息 / 命令（pxc ids 7–10, 20–27, 49–55, 91–96, 141） ​

这是主导频带：99 个 pxc 事件中约 30 个属于它。关键在于这些事件并非有 30 种不同布局，而是共享三种重复出现的载荷形状（外加少数单例）。相同形状的事件共享一个 Encode 处理器，这也是二进制文件本身折叠它们的方式。学会三个形状后，逐 id 表就只是 id→shape 的映射。所有事件都携带 TraceIdHeader{21,3,12}。

三种重复形状 ​

text
SHAPE-A  "OCI message"           CHECK=170 (2 pkts)   widths: 21,3,12 | 31,1,1,1,1,1,2,32,3
  fields: trace_id_header, msg_data(u32 31), done(bool 1), msg_type(enum), opcode(enum),
          {flag,flag}, node_type(enum 2), addr(u32 32), node_type_sel(enum 3)

SHAPE-B  "OCI descriptor common" CHECK=179 (2 pkts)   widths: 21,3,12 |
          2,2,3,2,2,3,2,13,2,1,1,1,13,3,13,3,16
  fields: trace_id_header, dma_type(enum 2), src_mem_mem_id(enum 2), src_mem_core_id(enum 3),
          src_opcode(enum 2), dst_mem_mem_id(enum 2), dst_mem_core_id(enum 3), dst_opcode(enum 2),
          src_sync_flag_id(u32 13), src_sync_flag_core_id(enum 2), {flag,flag,flag},
          dst_sync_flag_0_id(u32 13), dst_sync_flag_0_core_id(enum 3),
          dst_sync_flag_1_id(u32 13), dst_sync_flag_1_core_id(enum 3), program_counter(u32 16)

SHAPE-C  "OCI read/write command" CHECK=228 (2 pkts)  widths: 21,3,12 | 21,3,7,1,1,5 | 21,3,12 | 3,17,17,17,3
  fields: 3x trace_id_header (cmd0/cmd1/cmd2; cmd1 interleaves the scalar fields),
          index_valid(u32), id_index0/1/2(u32 17 each), node_type(enum 3)
```text

> **怪癖 —** SHAPE-C 嵌入**三个** `TraceIdHeader`（`cmd0`/`cmd1`/`cmd2`），也就是 `3 × 36 = 108` 位身份信息，之后才是标量载荷；这是唯一携带多个身份头的频带。中间的那个（`cmd1`，`21,3,7,1,1,5` 组）在第二和第三个身份记录之间交错放入命令标量，因此朴素的“先读三个头，再读载荷”解析器会使游标错位。必须严格按宽度序列读取：header、scalars、header、scalars。

### id → 形状映射

| id | 事件 | oneof | 形状 | CHECK | pkts |
|---|---|---|---|---|---|
| 7 | `OCI_MESSAGE_SENT_BY_UHI_BRIDGE` | 9 | A | 170 | 2 |
| 8 | `OCI_MESSAGE_RECEIVED_BY_UHI_BRIDGE` | 10 | A | 170 | 2 |
| 9 | `OCI_DESCRIPTOR_RECEIVED_BY_UHI_BRIDGE` | 11 | B | 179 | 2 |
| 10 | `OCI_DESCRIPTOR_SENT_BY_UHI_CLIENT` | 12 | B | 179 | 2 |
| 20 | `OCI_DESCRIPTOR_DESC_AT_QNM` | 13 | B | 179 | 2 |
| 21 | `OCI_GENERIC_DESC_ENQUEUED_AT_ENGINE` | 14 | — | 100 | 1 |
| 22 | `OCI_COMMON_READ_CMD_ISSUED_FROM_ENGINE` | 15 | C | 228 | 2 |
| 23 | `OCI_COMMON_MEM_READ_REQ_FROM_ENGINE` | 16 | C | 228 | 2 |
| 24 | `OCI_MESSAGE_MSG_ISSUED_FROM_ENGINE` | 17 | A | 170 | 2 |
| 25 | `OCI_MESSAGE_MSG_ISSUED_FROM_QNM` | 18 | A | 170 | 2 |
| 26 | `OCI_COMMON_WRITE_CMD_ACCEPTED_AT_MN` | 19 | C | 228 | 2 |
| 27 | `OCI_WRITE_REQ_MEM_WRITE_REQ_ISSUED_FROM_ENGINE` | 20 | — | 128 | 1 |
| 49 | `OCI_DESCRIPTOR_ENQUEUED_IN_ICR_EGRESS_DMA` | 30 | B | 179 | 2 |
| 50 | `OCI_MESSAGE_GENERATED_IN_ICR_EGRESS_DMA` | 31 | A | 170 | 2 |
| 51 | `OCI_MESSAGE_GENERATED_IN_ICR_INGRESS_DMA` | 32 | A | 170 | 2 |
| 52 | `OCI_MESSAGE_PACKET_SENT_TO_OCI` | 33 | A | 170 | 2 |
| 53 | `OCI_MESSAGE_PACKET_RECEIVED_IN_ICR` | 34 | A | 170 | 2 |
| 54 | `OCI_COMMON_OCI_WRITE_COMMAND` | 35 | C | 228 | 2 |
| 55 | `OCI_COMMON_OCI_READ_COMMAND` | 36 | C | 228 | 2 |
| 91 | `OCI_DESCRIPTOR_COMMON_ISSUED_FROM_TCS` | 48 | B+2 | 211 | 2 |
| 92–94 | `OCI_DESCRIPTOR_STRIDE_{SRC,DST,STEPS}_ISSUED_FROM_TCS` | 49–51 | stride | 195 | 2 |
| 95 | `OCI_MESSAGE_ISSUED_FROM_TCS` | 52 | A | 170 | 2 |
| 96 | `OCI_COMMON_COMPLETED_IN_TCS` | 53 | C | 228 | 2 |
| 141 | `OCI_MESSAGE_CMQ_VPU_DMA_MSG` | 91 | A | 170 | 2 |

### OCI 单例

三个 OCI id 不属于重复形状：

- **id 21 `OCI_GENERIC_DESC_ENQUEUED_AT_ENGINE`**（CHECK 100，1 pkt）— `21,3,12 | 3`：`TraceIdHeader` 加一个 3 位 enum/counter。最小的 OCI 事件。
- **id 27 `OCI_WRITE_REQ_MEM_WRITE_REQ_ISSUED_FROM_ENGINE`**（CHECK 128，1 pkt）— `21,3,12 | 1,15,12,3`：`req_origin`（enum，1）· `req_id`（uint32，15）· `src_cmd_id`（uint32，12）· `node_type`（enum，3）。正好填满一个 16 字节包（`61 + 67 = 128`）。
- **id 91 `OCI_DESCRIPTOR_COMMON_ISSUED_FROM_TCS`**（CHECK 211，2 pkts）— SHAPE-B 扩展两个额外字段（`+31,+1`）：TCS 发出的描述符变体。BC 发出的类似物（id 129，`OCI_DESCRIPTOR_COMMON_ISSUED_BY_BC`，oneof 84）共享这个 `B+2` 布局。

### OCI Stride 描述符（ids 92–94, 130–132）

```text
OciDescriptorStride{Src,Dst,Steps}IssuedFromTcs   CHECK=195 (2 pkts)
  widths: 21,3,12 | 31,1,1,1,32,32
  fields: trace_id_header, {src,dst,steps}_stride_0/1/2 (3 × uint32 reassembled from 31/32/32)

三个 stride 值是用于 strided DMA 描述符的设备地址步长，以 32 位片段承载。BC 发出的类似物（ids 130–132，oneof 85–87）共享该布局。

node_type 选择器 ​

node_type enum 在 SHAPE-A/-C 中反复出现：node_type ∈ {TCS, BC, CMQ, HBMQ, UHI, ICR, QNM}（7 个值；3 位字段）。integer→name 表位于 trace_entries.proto 的嵌套 *Values enum 中，此处没有逐值枚举（对精确整数顺序置信度 LOW）。解码器锚点：DecodeOciCommonOciReadCommand @ 0xf5b8dc0（3 个 TraceIdHeader，oneof 0x24，CHECK 228），DecodeOciDescriptorDescAtQnm @ 0xf5b34a0（SHAPE-B，oneof 13，CHECK 179）。

ICI — 芯片间链路包（pxc ids 40–48） ​

集合 fabric 的物理基底。全部九个 ICI 事件在每个 family 内共享一个载荷形状，它们只在触发的是哪个生命周期阶段上不同（链路接收、传输、排队、ICR DMA bridge 注入/接收 control/data、control/data 为本地 ingress 排队）。每个事件都是单个 16 字节包。

pxc（pufferfish）— CHECK 125，1 pkt ​

text
TraceIdHeader{21,3,12}, widths: 21,3,12 | 3,3,6,1,1,12,1,1
  router_link_port_id     enum 3    LINK0..LINK5 (6 router ports ⇒ 3 bits)
  virtual_channel         u32  3
  link_targets            u32  6
  local_ingress_target    bool 1
  multicast               bool 1
  dst_chip_id             u32  12
  first_packet_in_dma     bool 1
  last_packet_in_dma      bool 1
```text

| id | 事件 | oneof |
|---|---|---|
| 40 | `ICI_PACKET_PACKET_RECEIVED_ON_LINK_INPUT` | 21 |
| 41 | `ICI_PACKET_PACKET_TRANSMITTED_ON_LINK_OUTPUT` | 22 |
| 42 | `ICI_PACKET_PACKET_QUEUED_FOR_LINK_TRANSMISSION` | 23 |
| 43 | `ICI_PACKET_CONTROL_PACKET_INJECTED_BY_ICR_DMA_BRIDGE` | 24 |
| 44 | `ICI_PACKET_DATA_PACKET_INJECTED_BY_ICR_DMA_BRIDGE` | 25 |
| 45 | `ICI_PACKET_CONTROL_PACKET_RECEIVED_BY_ICR_DMA_BRIDGE` | 26 |
| 46 | `ICI_PACKET_DATA_PACKET_RECEIVED_BY_ICR_DMA_BRIDGE` | 27 |
| 47 | `ICI_PACKET_CONTROL_PACKET_QUEUED_FOR_LOCAL_INGRESS` | 28 |
| 48 | `ICI_PACKET_DATA_PACKET_QUEUED_FOR_LOCAL_INGRESS` | 29 |

九个事件全部映射到同一个解码器形状（`DecodeIciPacketPacketReceivedOnLinkInput` @ `0xf5b56c0` 是代表，oneof `0x15`=21，CHECK `0x7d`=125）。control-vs-data 和 injected-vs-received 的区别完全存在于 `trace_point_id` 中，而不在载荷中。

### glc（ghostlite）— CHECK 128，1 pkt

```text
TraceIdHeader{21,3,14}, widths: 21,3,14 | 3,2,6,1,1,14,1,1
  same field names; virtual_channel narrows 3→2, dst_chip_id widens 12→14

怪癖 — ghostlite 的 ICI 事件从 125 位增长到 128 位，但仍然适配一个包。两个漂移相互补偿：dst_chip_id 从 12 位扩展到 14 位（跟随 TraceIdHeader 中的 14 位 chip_id），而 virtual_channel 从 3 位收窄到 2 位。硬编码 pxc 的 12 位 dst_chip_id 或 pxc 的 3 位 virtual_channel 的重新实现，会在 glc/gfc 上使其后每个字段错位。应从逐 family 解码器驱动宽度，而不是用单一常量。解码器锚点：glc DecodeIciPacketPacketReceivedOnLinkInput @ 0xf6322c0（oneof 25，CHECK 0x80=128）。

片内 DMA — CMQ VPU-DMA（pxc ids 140–149） ​

pufferfish 上由片上 DMA started/completed 组成的频带是 CMQ（compute-memory-queue）VPU-DMA：八个定向 VMEM↔CMEM 传输，加一个描述符事件和一个 OCI-message 事件。全部为单包。全部携带 TraceIdHeader{21,3,12}。

id事件oneofCHECKpkts宽度（21,3,12 | payload）
140CMQ_VPU_DMA_DESC90105121,3,12 | 8
141OCI_MESSAGE_CMQ_VPU_DMA_MSG91170221,3,12 | 31,1,1,1,1,1,2,32,3（SHAPE-A）
142CMQ_VPU_DMA_REQ_VMEM0_TO_CMEM_READ92123121,3,12 | 2,4,20
143CMQ_VPU_DMA_REQ_VMEM0_TO_CMEM_WRITE93123121,3,12 | 2,4,20
144CMQ_VPU_DMA_REQ_CMEM_TO_VMEM0_READ94123121,3,12 | 2,4,20
145CMQ_VPU_DMA_REQ_CMEM_TO_VMEM0_WRITE95123121,3,12 | 2,4,20
146CMQ_VPU_DMA_REQ_VMEM1_TO_CMEM_READ96123121,3,12 | 2,4,20
147CMQ_VPU_DMA_REQ_VMEM1_TO_CMEM_WRITE97123121,3,12 | 2,4,20
148CMQ_VPU_DMA_REQ_CMEM_TO_VMEM1_READ98123121,3,12 | 2,4,20
149CMQ_VPU_DMA_REQ_CMEM_TO_VMEM1_WRITE99123121,3,12 | 2,4,20

八个定向 DMA-req 事件（142–149）字节相同：access_type（enum，2）· vpu_channels（uint32，4）· addr（uint32，20）= 62 个载荷位；方向只编码在 trace_point_id 中，绝不在载荷中。描述符事件（140）携带单个 8 位选择器；消息事件（141）复用 OCI SHAPE-A。解码器锚点：DecodeCmqVpuDmaReqVmem0ToCmemRead @ 0xf5c4700（oneof 92，CHECK 0x7b=123），DecodeCmqVpuDmaDesc @ 0xf5c40c0（oneof 90，CHECK 0x69=105）。

各代后继 — CMN-DMA，glc ids 72–79 ​

Ghostlite 用 CMN-DMA（chip-memory-network DMA）取代 CMQ，这是一个丰富得多的记录，会暴露显式 router 路由以及 opcode/mem-id 端点。TraceIdHeader{21,3,14}。

text
CmnDmaRequestEastSideLane0   oneof 43   CHECK=205 (2 pkts)
  widths: 21,3,14 | 3,10,1,1,5,5,2,2,1,1,1,32,2,3,32,4,1
  thread_id(enum 3), req_id(u32 10),
  cmn_uncore_router_id_valid0/1(bool,bool), cmn_uncore_router_id0/1(u32 5,u32 5),
  src_opcode(enum 2), src_mem_id(enum 2), src_operand(u32 1+1+1+32 reassembled),
  dst_opcode(enum 2), dst_mem_id(enum 3), dst_addr(u32 32), beats(u32 4), poison(bool 1)
```text

pxc CMQ 事件只记录 `{access_type, vpu_channels, addr}`；较新的 mem-network trace 增加了 router 端点、源/目的 opcode 和 mem-id、beat 计数，以及 `poison` 标志。解码器锚点：`DecodeCmnDmaRequestEastSideLane0` @ `0xf6368e0`（oneof 43，CHECK `0xcd`=205）。lane/side 变体（72–79）共享该布局。

---

## TCS Sync-Flag 原语（pxc ids 80–90）

TensorCore-Sequencer 内部频带：片上 semaphore/fence 原语（set / add / read / wait / scalar-fence）。"WaitSyncFlag" 语义拆成两个事件：`UNSUCCESSFUL_SYNC_ATTEMPT`（被阻塞的 wait）和 `SUCCESSFUL_SYNC_ATTEMPT`（解除阻塞的 wait）。

> **说明 —** TCS 内部事件（ids 81–90）**不**携带 `TraceIdHeader`，core 由 59 位 header 中的 `trace_point_block_id` 暗含，因此载荷直接从 bit 61 开始。只有 id 80（`TCS_EXTERNAL_SYNC_FLAG_UPDATE_DMA_DONE`）这个跨芯片完成事件携带身份信息。

### pxc — 10 个内部事件共享一个形状，CHECK 121，1 pkt

```text
widths (no TIDhdr): 32,1,9,16,1,1
  data_field           u32  32   (some events store sync_flag_number here)
  done_bit             bool 1
  sync_flag_number     u32  9
  program_counter      u32  16
  sfence_end           bool 1
  sfence_start         bool 1
id事件oneof
81TCS_INTERNAL_SET_SYNC_FLAG38
82TCS_INTERNAL_ADD_SYNC_FLAG39
83TCS_INTERNAL_HOST_INTERRUPT40
84TCS_INTERNAL_SET_TRACEMARK41
85TCS_INTERNAL_TRACE_INSTRUCTION42
86TCS_INTERNAL_UNSUCCESSFUL_SYNC_ATTEMPT（wait blocked）43
87TCS_INTERNAL_SUCCESSFUL_SYNC_ATTEMPT（wait unblocked）44
88TCS_INTERNAL_READ_SYNC_FLAG45
89TCS_INTERNAL_SCALAR_FENCE_START46
90TCS_INTERNAL_SCALAR_FENCE_END47

怪癖 — TCS_INTERNAL_SET_SYNC_FLAG（id 81）有三个内部 proto oneof 子标签（0x26/0x27/0x28），它们都把相同的 32,1,9,16,1,1 线形状解码为三种不同 proto 变体（set / set-and-trace / 等），全部 CHECK 121。一个线布局，三个 proto case；判别器是子标签戳，而不是载荷位。解码器锚点：DecodeTcsInternalSetSyncFlag @ 0xf5b97a0（子标签位于 0xf5b985e/0xf5b9a7e/0xf5b9c9e，CHECK 0x79=121）。

id 80 — 跨芯片完成，CHECK 163，2 pkts ​

text
TCS_EXTERNAL_SYNC_FLAG_UPDATE_DMA_DONE   oneof 37   CHECK=163 (2 pkts)
  widths: 21,3,12 | 31,1,1,1,1,9,16,1,1,1,1,1,1
  trace_id_header,
  updated_sync_flag_value(u32 31), updated_sync_flag_done(bool), sync_flag_number(u32 9),
  program_counter(u32 16), then 6 bools:
    successful_sync_unblock, successful_sync, last_sync_for_dma, last_sync_was_add,
    was_csr_update, trace_bit_set
```text

这是 bump 本地 sync flag 的*远程* DMA 的接收侧完成，也就是 `BumpRemoteSyncFlag` / atomic set-done 的 trace 观察。解码器锚点：`DecodeTcsExternalSyncFlagUpdateDmaDone` @ `0xf5b9340`（oneof 37，CHECK `0xa3`=163）。

### 各代 — glc SetSyncFlag 扩展，CHECK 187，2 pkts

```text
widths (no TIDhdr): 32,1,9,16,1,1, 7,1,1,57
  base {32,1,9,16,1,1} identical to pxc, then +lcc (uint64) reassembled from {7,1,1,57}

Ghostlite 追加了一个 lcc（loop/cycle-counter）64 位字段，使 sync-flag 载荷从 60 位增长到 126 位（pxc→glc）。解码器锚点：glc DecodeTcsInternalSetSyncFlag @ 0xf6380c0（oneof 48，CHECK 0xbb=187）。glc TcsExternalSyncFlagUpdateDmaDone 同样增加了字段（CHECK 0xa5=165）。

Throttle / Stall（pxc id 97） ​

THROTTLE_STATE_THERMAL_AND_ELECTRICAL 是一个带判别的双变体 body，也就是单个 trace_point_id，其第一个 4 位字段（packet_type）选择其余包内容使用两个 proto 变体和两种载荷布局中的哪一个。解码器基于 packet_type & 1 分支，并写入不同 oneof 标签。没有 TraceIdHeader；power 事件是芯片全局的。

text
VARIANT A  oneof=54 (packet_type bit0=0)   CHECK=120 (1 pkt)
  widths: 4,5,5,10,4,21,5,5
  packet_type(enum 4), num_electrical_throttles(u32 5), num_thermal_throttles(u32 5),
  thermal_sensor_data(u32 10), thermal_sensor_index(u32 4), thermal_total_throttles(u32 21),
  thermal_max_throttle(u32 5), thermal_min_throttle(u32 5)

VARIANT B  oneof=55 (packet_type bit0=1)   CHECK=204 (2 pkts)
  widths: 13,16,16,22,1,1  then  10,16,16,16,13,1,2  (two internal sub-branches, both CHECK 204)
  a wider electrical/voltage throttle record: the 16-bit fields are voltage/current samples,
  the 22-bit is a cycle/throttle accumulator
```text

> **陷阱 —** 同一个 `trace_point_id`（97）会解码到两个不同 proto oneof 字段（54 与 55）、两个不同载荷宽度，以及两个不同包数（1 与 2），并在运行时由一个载荷位（`packet_type & 1`）选择。纯粹以 `trace_point_id` 为键的解码器会错误估计变体 B 的大小。判别器位于*载荷内部*，在分支前读取。解码器锚点：`DecodeThrottleStateThermalAndElectricalThrottleState` @ `0xf5bc620` — 变体 A 位于 `0xf5bc6de`（`test $0x1`，CHECK `0x78`=120，bytes `0x10`），变体 B 位于 `0xf5bc945`（CHECK `0xcc`=204，位于 `0xf5bcb73`/`0xf5bcef3`，bytes `0x20`）。
>
> **说明 —** 变体 B 有两个尾部宽度子分支（`13,16,16,22,1,1` 与 `10,16,16,16,13,1,2`），它们都验证到*相同* CHECK（204）和*相同* oneof（55）。内部分支究竟是第二个 `packet_type` 位还是长度条件重解码尚未解决（对精确内部谓词置信度 LOW）；两个子分支读取的尾部宽度略有不同，但汇合到 CHECK 204，因此应把它们视为一对带判别的布局。变体 A/B 的外层判别器（`packet_type & 1`）和两个 CHECK 常量为 CERTAIN。

### BarnaCore FSM 复用（ids 100–119）

BarnaCore FSM 事件复用 throttle 变体 B 的字布局：ids 100–115（`BC_FSM_CHANNEL_CONTROLLER0..15`）和 116–119（`BC_FSM_{PROCESS_HOSTID,SPARSE_REDUCE,PROCESS_BCID,CONCAT}`）都解码为 `13,16,16,22,1,1,10,16,16,16,13,1,2` 形状，CHECK 204，2 pkts（HIGH 置信度：相同字布局，oneof 字段 55–74）。

### 各代 — glc cycle-skip throttle（ids 200–218）

Ghostlite 提供大得多的 throttle family：19 个 cycle-skip 事件，每个都携带 `TraceIdHeader{21,3,14}` 和一个小的 stall-count 载荷。

```text
THROTTLE_CYCLE_SKIP_THERMAL   glc   oneof 118   CHECK=104 (1 pkt)
  widths: 21,3,14 | 5     trace_id_header + 5-bit cycle-skip count

cycle-skip 计数就是 stall：每个事件记录引擎因该原因（THERMAL、EXT_BRAKE、EXT_THROTTLE、LDIDT_BRAKE、LDIDT_DROOP、ARBITRATION、PPM_*）跳过了多少个时钟周期（被 throttle）。Ids 200–217 共享 … | 5 stall-count 形状；THROTTLE_LDIDT_RUNNING_MEAN_VOLTAGE（218）携带更宽的电压样本（HIGH 置信度）。

完整 pxc 逐事件参考（99 个事件） ​

完整的 pufferfish trace_point_id → oneof → CHECK(pkts) → widths 表，每行都从其 Decode<Name> 字节精确读取。上面的频带给出了命名字段；这里是索引。保留 id 范围（11–19、28–39、56–79、98–99）路由到公共错误标签，没有载荷。

text
id  EVENT                                                  oneof CHECK(pk) widths [TIDhdr|payload]
── HOST / UHI ──────────────────────────────────────────────────────────────────────────────────
 0  UHI_HOST_DMA_TRANSACTION_STARTED_ADDRESS_TRANSLATION    f2  216(2)  21,3,12,5,16,10,1,1,54,32
 1  UHI_HOST_PHYSICAL_REQUEST_READ                          f3  233(2)  21,3,12,1,30,1,1,29,26,8,20,20
 2  UHI_HOST_PHYSICAL_RESPONSE_READ                         f4  118(1)  21,3,12,1,20
 3  UHI_HOST_PHYSICAL_REQUEST_WRITE                         f5  233(2)  21,3,12,1,30,1,1,29,26,8,20,20
 4  UHI_HOST_PHYSICAL_RESPONSE_WRITE                        f6  118(1)  21,3,12,1,20
 5  UHI_OCI_REQUEST_READ                                    f7  165(2)  21,3,12,31,1,1,19,14,1,1
 6  UHI_OCI_REQUEST_WRITE                                   f8  165(2)  21,3,12,31,1,1,19,14,1,1
 7  OCI_MESSAGE_SENT_BY_UHI_BRIDGE                          f9  170(2)  21,3,12,31,1,1,1,1,1,2,32,3        [A]
 8  OCI_MESSAGE_RECEIVED_BY_UHI_BRIDGE                      f10 170(2)  21,3,12,31,1,1,1,1,1,2,32,3        [A]
 9  OCI_DESCRIPTOR_RECEIVED_BY_UHI_BRIDGE                   f11 179(2)  21,3,12,2,2,3,2,2,3,2,13,2,1,1,1,13,3,13,3,16  [B]
10  OCI_DESCRIPTOR_SENT_BY_UHI_CLIENT                       f12 179(2)  21,3,12,2,2,3,2,2,3,2,13,2,1,1,1,13,3,13,3,16  [B]
── OCI engine ──────────────────────────────────────────────────────────────────────────────────
20  OCI_DESCRIPTOR_DESC_AT_QNM                              f13 179(2)  21,3,12,…[B]
21  OCI_GENERIC_DESC_ENQUEUED_AT_ENGINE                     f14 100(1)  21,3,12,3
22  OCI_COMMON_READ_CMD_ISSUED_FROM_ENGINE                  f15 228(2)  21,3,12,21,3,7,1,1,5,21,3,12,3,17,17,17,3  [C]
23  OCI_COMMON_MEM_READ_REQ_FROM_ENGINE                     f16 228(2)  21,3,12,…[C]
24  OCI_MESSAGE_MSG_ISSUED_FROM_ENGINE                      f17 170(2)  21,3,12,…[A]
25  OCI_MESSAGE_MSG_ISSUED_FROM_QNM                         f18 170(2)  21,3,12,…[A]
26  OCI_COMMON_WRITE_CMD_ACCEPTED_AT_MN                     f19 228(2)  21,3,12,…[C]
27  OCI_WRITE_REQ_MEM_WRITE_REQ_ISSUED_FROM_ENGINE          f20 128(1)  21,3,12,1,15,12,3
── ICI + ICR DMA ───────────────────────────────────────────────────────────────────────────────
40  ICI_PACKET_PACKET_RECEIVED_ON_LINK_INPUT               f21 125(1)  21,3,12,3,3,6,1,1,12,1,1
41  ICI_PACKET_PACKET_TRANSMITTED_ON_LINK_OUTPUT           f22 125(1)  21,3,12,3,3,6,1,1,12,1,1
42  ICI_PACKET_PACKET_QUEUED_FOR_LINK_TRANSMISSION         f23 125(1)  21,3,12,3,3,6,1,1,12,1,1
43  ICI_PACKET_CONTROL_PACKET_INJECTED_BY_ICR_DMA_BRIDGE   f24 125(1)  21,3,12,3,3,6,1,1,12,1,1
44  ICI_PACKET_DATA_PACKET_INJECTED_BY_ICR_DMA_BRIDGE      f25 125(1)  21,3,12,3,3,6,1,1,12,1,1
45  ICI_PACKET_CONTROL_PACKET_RECEIVED_BY_ICR_DMA_BRIDGE   f26 125(1)  21,3,12,3,3,6,1,1,12,1,1
46  ICI_PACKET_DATA_PACKET_RECEIVED_BY_ICR_DMA_BRIDGE      f27 125(1)  21,3,12,3,3,6,1,1,12,1,1
47  ICI_PACKET_CONTROL_PACKET_QUEUED_FOR_LOCAL_INGRESS     f28 125(1)  21,3,12,3,3,6,1,1,12,1,1
48  ICI_PACKET_DATA_PACKET_QUEUED_FOR_LOCAL_INGRESS        f29 125(1)  21,3,12,3,3,6,1,1,12,1,1
49  OCI_DESCRIPTOR_ENQUEUED_IN_ICR_EGRESS_DMA              f30 179(2)  21,3,12,…[B]
50  OCI_MESSAGE_GENERATED_IN_ICR_EGRESS_DMA                f31 170(2)  21,3,12,…[A]
51  OCI_MESSAGE_GENERATED_IN_ICR_INGRESS_DMA               f32 170(2)  21,3,12,…[A]
52  OCI_MESSAGE_PACKET_SENT_TO_OCI                         f33 170(2)  21,3,12,…[A]
53  OCI_MESSAGE_PACKET_RECEIVED_IN_ICR                     f34 170(2)  21,3,12,…[A]
54  OCI_COMMON_OCI_WRITE_COMMAND                           f35 228(2)  21,3,12,…[C]
55  OCI_COMMON_OCI_READ_COMMAND                            f36 228(2)  21,3,12,…[C]
── TCS sequencer ───────────────────────────────────────────────────────────────────────────────
80  TCS_EXTERNAL_SYNC_FLAG_UPDATE_DMA_DONE                 f37 163(2)  21,3,12,31,1,1,1,1,9,16,1,1,1,1,1,1
81  TCS_INTERNAL_SET_SYNC_FLAG                             f38 121(1)  32,1,9,16,1,1   (sub-tags 0x26/0x27/0x28)
82  TCS_INTERNAL_ADD_SYNC_FLAG                             f39 121(1)  32,1,9,16,1,1
83  TCS_INTERNAL_HOST_INTERRUPT                            f40 121(1)  32,1,9,16,1,1
84  TCS_INTERNAL_SET_TRACEMARK                             f41 121(1)  32,1,9,16,1,1
85  TCS_INTERNAL_TRACE_INSTRUCTION                         f42 121(1)  32,1,9,16,1,1
86  TCS_INTERNAL_UNSUCCESSFUL_SYNC_ATTEMPT                 f43 121(1)  32,1,9,16,1,1   (wait blocked)
87  TCS_INTERNAL_SUCCESSFUL_SYNC_ATTEMPT                   f44 121(1)  32,1,9,16,1,1   (wait unblocked)
88  TCS_INTERNAL_READ_SYNC_FLAG                            f45 121(1)  32,1,9,16,1,1
89  TCS_INTERNAL_SCALAR_FENCE_START                        f46 121(1)  32,1,9,16,1,1
90  TCS_INTERNAL_SCALAR_FENCE_END                          f47 121(1)  32,1,9,16,1,1
91  OCI_DESCRIPTOR_COMMON_ISSUED_FROM_TCS                  f48 211(2)  21,3,12,…[B]+31,1
92  OCI_DESCRIPTOR_STRIDE_SRC_ISSUED_FROM_TCS              f49 195(2)  21,3,12,31,1,1,1,32,32
93  OCI_DESCRIPTOR_STRIDE_DST_ISSUED_FROM_TCS              f50 195(2)  21,3,12,31,1,1,1,32,32
94  OCI_DESCRIPTOR_STRIDE_STEPS_ISSUED_FROM_TCS            f51 195(2)  21,3,12,31,1,1,1,32,32
95  OCI_MESSAGE_ISSUED_FROM_TCS                            f52 170(2)  21,3,12,…[A]
96  OCI_COMMON_COMPLETED_IN_TCS                            f53 228(2)  21,3,12,…[C]
97  THROTTLE_STATE_THERMAL_AND_ELECTRICAL                  f54/f55 120(1)/204(2)  A: 4,5,5,10,4,21,5,5 | B: 13,16,16,22,…/10,16,16,16,13,1,2
── BarnaCore + CMQ ─────────────────────────────────────────────────────────────────────────────
100-115 BC_FSM_CHANNEL_CONTROLLER0..15                     f55-f70 204(2) 13,16,16,22,1,1,10,16,16,16,13,1,2 (all identical)
116-119 BC_FSM_{PROCESS_HOSTID,SPARSE_REDUCE,PROCESS_BCID,CONCAT} f71-f74 204(2) same BC-FSM word
120-124 BCS_{TRACE_INSTRUCTION,SET_TRACEMARK,SYNC_START_STOP_TRACE,HOST_INTERRUPT,FENCE} f75-f79 127(1) 32,3,16,13,1,1
125-128 BC_OCI_{READ_REQUEST,READ_RESPONSE,WRITE_REQUEST,WRITE_RESPONSE} f80-f83 193(2) 21,3,12,4,16,11,1,1,37,5,1,20
129 OCI_DESCRIPTOR_COMMON_ISSUED_BY_BC                     f84 211(2)  21,3,12,…[B]+31,1
130-132 OCI_DESCRIPTOR_STRIDE_{SRC,DST,STEPS}_ISSUED_BY_BC f85-f87 195(2) 21,3,12,31,1,1,1,32,32
133 OCI_MESSAGE_RECEIVED_BY_BC                             f88 170(2)  21,3,12,…[A]
134 OCI_MESSAGE_SENT_BY_BC                                 f89 170(2)  21,3,12,…[A]
140 CMQ_VPU_DMA_DESC                                       f90 105(1)  21,3,12,8
141 OCI_MESSAGE_CMQ_VPU_DMA_MSG                            f91 170(2)  21,3,12,…[A]
142-149 CMQ_VPU_DMA_REQ_*                                  f92-f99 123(1) 21,3,12,2,4,20 (all 8 identical)
── Sentinel ────────────────────────────────────────────────────────────────────────────────────
255 DUMMY_TRACE_ENTRY_DUMMY_TRACE_POINT                    f100 128(1) 21,3,12,31
```text

> **说明 —** 非 pxc family（vfc/vlc/glc/gfc）使用*相同*解析器解码，帧是 family 不变的，但它们完整的逐事件宽度表没有在此列出。六个高价值频带已在 glc 上解码，以固定各代 delta（`chip_id` 12→14、`dst_chip_id` 12→14、`virtual_channel` 3→2、`+lcc` sync-flag 增长、HDE/CMN-DMA 后继）。剩余约 480 个变体（122 vfc + 78 vlc + 135 glc + 144 gfc，减去这里的频带）可用相同宽度提取方法从每个 `Decode<Name>` 机械 dump；它们在完整性上置信度 LOW，故不在此复现。较新 family 的 delta 由 [Payload: vfc/vlc/gfc](payload-vfc-vlc-gfc.md) 负责；SparseCore `SC_*` 频带由 [Payload: SparseCore 频带](payload-sc-band.md) 负责；jxc `PerformanceTraceEntry` schema 由 [Payload: jxc 旧版](payload-jxc-legacy.md) 负责。

---

## 选择器 Enum 与重组空缺

两类细节有意不列入表中，因为它们位于本页读取的解码函数之外：

- **选择器 integer→name 表。** 上面已解码每个选择器的位*宽度*；integer→name 映射（`dma_type`、`node_type ∈ {TCS,BC,CMQ,HBMQ,UHI,ICR,QNM}`、`router_link_port_id ∈ {LINK0..LINK5}`、`core_id ∈ {RESERVED,NONCORE,TC0,TC1,BC0..BC3}`、`access_type`、`queue_id`、`thread_id`、`src/dst_opcode`、`src/dst_mem_id`）位于每个 `trace_entries.proto` 的嵌套 `*Values` enum 中，可从 FDP descriptor pool 恢复，但此处未逐值枚举（对精确整数顺序置信度 LOW）。
- **uint64 片段重组。** 对于以多个 `GetBits64` 片段读取的宽于 32 位字段（`dpa_upper_bits` 30+29、`address` 26+33、`dva` 1+1+54、`src_operand`、`lcc` 7+1+1+57），*宽度和目标槽*（`TraceEntry+0xNN`）为 CERTAIN，但 64 位值内部精确的逐片段 shift/OR 位位置只对命名频带做过追踪（对精确重组顺序置信度 LOW；重新编码器必须逐字段恢复它，才能对 >32 位字段做到字节精确）。

---

## 解码器证据锚点

| 事件 / 组 | 解码器 | 地址 | CHECK | 置信度 |
|---|---|---|---|---|
| UHI 地址转换 | `DecodeUhiHostDmaTransactionStartedAddressTranslation` | `0xf5b0b80` | 216 | CERTAIN |
| UHI 物理读请求 | `DecodeUhiHostPhysicalRequestRead` | `0xf5b0f20` | 233 | CERTAIN |
| UHI 物理读响应 | `DecodeUhiHostPhysicalResponseRead` | `0xf5b1300` | 118 | CERTAIN |
| UHI OCI 读请求 | `DecodeUhiOciRequestRead` | `0xf5b1be0` | 165 | CERTAIN |
| OCI 读命令（SHAPE-C） | `DecodeOciCommonOciReadCommand` | `0xf5b8dc0` | 228 | CERTAIN |
| OCI 描述符（SHAPE-B） | `DecodeOciDescriptorDescAtQnm` | `0xf5b34a0` | 179 | CERTAIN |
| ICI 链路包（pxc） | `DecodeIciPacketPacketReceivedOnLinkInput` | `0xf5b56c0` | 125 | CERTAIN |
| ICI 链路包（glc） | `DecodeIciPacketPacketReceivedOnLinkInput` | `0xf6322c0` | 128 | HIGH |
| TCS set sync flag（pxc） | `DecodeTcsInternalSetSyncFlag` | `0xf5b97a0` | 121 | CERTAIN |
| TCS set sync flag（glc，+lcc） | `DecodeTcsInternalSetSyncFlag` | `0xf6380c0` | 187 | HIGH |
| TCS external sync done | `DecodeTcsExternalSyncFlagUpdateDmaDone` | `0xf5b9340` | 163 | CERTAIN |
| Throttle 双变体 | `DecodeThrottleStateThermalAndElectricalThrottleState` | `0xf5bc620` | 120 / 204 | CERTAIN |
| CMQ VPU-DMA req | `DecodeCmqVpuDmaReqVmem0ToCmemRead` | `0xf5c4700` | 123 | CERTAIN |
| CMQ VPU-DMA desc | `DecodeCmqVpuDmaDesc` | `0xf5c40c0` | 105 | CERTAIN |
| HDE host request（glc） | `DecodeHdeHostRequestRead` | `0xf62e660` | 178 | HIGH |
| CMN-DMA request（glc） | `DecodeCmnDmaRequestEastSideLane0` | `0xf6368e0` | 205 | HIGH |
| bit-codec 原语 | `BitDecoder::GetBits64NoInline` | `0x21073760` | — | CERTAIN |
| 宽度 mask 表 | `mask_`（`mask_[k]=(1<<k)-1`） | `0xbe79440` | — | CERTAIN |

上述所有 `Decode<Name>` 起始地址都已通过二进制文件的符号表（`…_functions.json`）确认：每个匿名命名空间解码器都以完整 mangled name（`asic_sw::driver::deepsea::pxc::profiler::(anonymous namespace)::Decode<Name>(string_view, bool*, TraceEntry*)`）存在于所列地址。`mask_` 字节精确地包含每个已用宽度（`mask_[1..3,8,12,14,16,21,30,45,48]`），确认这些字段宽度是真实读取 mask，而非推断。

---

## 相关组件

| 组件 | 关系 |
|---|---|
| [TraceEntriesCoder](trace-entries-coder.md) | 负责 16 字节包、帧前缀、`TraceHeader`/`TraceIdHeader`、双派发，以及本页载荷所在的逐事件 `CHECK` 机制 |
| [TracePoints 主注册表](tracepoints-master-registry.md) | 负责 `trace_point_id` → name 和 id ↔ oneof-field 注册表；本页解码这些 id 所命名的载荷 |
| [Payload: SparseCore 频带](payload-sc-band.md) | SparseCore `SC_*` 频带的载荷字段映射 |
| [Payload: vfc/vlc/gfc](payload-vfc-vlc-gfc.md) | 较新 family 的载荷 delta（6 位 `block_id`、45 位 timestamp、14 位 `chip_id`）以及剩余逐事件表 |
| [Payload: jxc 旧版](payload-jxc-legacy.md) | 独立的 `PerformanceTraceEntry` schema 及其 codec |
| [UHI Host Interface](../dma/uhi-host-interface.md) | UHI trace 频带观察其事务的 host-DMA 引擎 |
| [OCI Command DMA ID](../dma/oci-command-dma-id.md) | 这些 OCI trace 事件携带的 OCI command/descriptor DMA 身份 |
| [ICI DMA Descriptor](../ici/dma-descriptor.md) | ICI 链路包事件传输的芯片间 DMA 描述符 |

## 交叉引用

- [Profiling and Telemetry 概览](overview.md) — 五阶段 capture→encode→decode→xplane 流水线；这些载荷是第 3 阶段的设备事件内容
- [TraceEntriesCoder](trace-entries-coder.md) — 请先阅读：每个本页载荷都扩展的通用 frame（16 字节包、61 位 envelope、双派发、总位数 `CHECK`）
- [TracePoints 主注册表](tracepoints-master-registry.md) — wire-id / oneof-field id 空间；本页是该注册表名称的载荷附录
- [Payload: SparseCore 频带](payload-sc-band.md) · [Payload: vfc/vlc/gfc](payload-vfc-vlc-gfc.md) · [Payload: jxc 旧版](payload-jxc-legacy.md) — 本页不负责的频带的 sibling payload 页面
- [UHI Host Interface](../dma/uhi-host-interface.md) · [OCI Command DMA ID](../dma/oci-command-dma-id.md) · [ICI DMA Descriptor](../ici/dma-descriptor.md) — 这些 trace 频带所观测硬件引擎的子系统页面