SparseCoreTarget (Target+0x948)

本页中的每个 offset、value 和 address 都是从 libtpu-0.0.40-cp314 wheel 中的 libtpu.so (BuildID md5 89edbbe81c5b328a958fe628a9f2207d) 逐字节读取的。其他版本会有所不同。

摘要

xla::jellyfish::Target 是按代际划分的硬件 descriptor，XLA TPU 后端会为每个 codegen 和成本决策查询它。该 descriptor 的 SparseCore 部分并不内联存在于 Target 中；它是一个单独分配的 std::unique_ptr<xla::jellyfish::SparseCoreTarget>，停放在 Target+0x948。本页是该子对象的完整字段映射、进入它的 accessor 表面，以及按代际的 MXU-contracting-depth 表；后者与它一起存在于按代号划分的 Target 子类中，并且是从这个 wheel 中可恢复的最干净的按代号 MXU 区分项。

三个具体事实驱动本页，重新实现者需要全部三个：

• SparseCore 存在性是被门控的，而不是默认假定的。 每个 Target::SparseCore* accessor 首先调用一个虚拟谓词 (SupportsSparseCore, vtable 槽 +0x260)，如果为 false 就 LOG(FATAL)。Target+0x948 指针只在带有 SparseCore 的代际上填充；在 BarnaCore 代际 (Jellyfish/Dragonfish/Pufferfish) 和仅 TensorCore 的 lite die 上，guard 会在指针被解引用之前短路。
• 发布了三个 SparseCoreTarget 类。 一个基类 SparseCoreTarget 加两个具体子类：ViperfishSparseCoreTarget (v5p) 和 GhostLiteSparseCoreTarget (v6e Ghostlite 以及 v7x 6acc60406)。按代际的 capability bit、latency 和 FLOPS 是这些子类 virtual 中的 C++ 字面量。
• MXU contracting depth 是编译进来的字面量。 基类 Target::MxuContractingSize 返回 128；只有 GhostliteTarget 将其 override 为 256。这个 128-vs-256 拆分是此 build 中唯一硬编码的按代号 MXU-geometry 值，并且它不是 chip_parts proto 字段。

子对象	std::unique_ptr<xla::jellyfish::SparseCoreTarget> at Target+0x948
构建者	SparseCoreTarget::Init @ 0x1D612B20，由 Target::Init 安装
存在性门控	Target::SupportsSparseCore @ 0x1D48FD40 (vtable 槽 +0x260)
具体类	base / ViperfishSparseCoreTarget / GhostLiteSparseCoreTarget
有 SparseCore	Viperfish (v5p), Ghostlite (v6e), 6acc60406 (v7x)
无 SparseCore	Jellyfish / Dragonfish / Pufferfish (BarnaCore); lite dies (none)
置信度	CONFIRMED (byte-anchored)，除非某行另有说明

---

存在性门控

Target+0x948 只有在 target 具有 SparseCore 硅时才有意义。决定这一点的谓词是 Target::SupportsSparseCore @ 0x1D48FD40，它不会测试 +0x948 指针；它从 Target+0x3B8 处的 TpuTopology 子对象读出一个计数：

// Target::SupportsSparseCore @ 0x1D48FD40
bool Target::SupportsSparseCore(Target *this) {
  // (this + 119) == Target+0x3B8 == TpuTopology*; field +0x98 is an SC count
  return *(uint32_t *)(*(uintptr_t *)(this + 0x3B8) + 0x98) > 0;
}
```text

它接入 vtable 槽 `+0x260`。下一节中的每个标量 accessor 都会在触碰 `Target+0x948` 前经由该槽 dispatch，因此在 BarnaCore 代际上，accessor 会以 `"SparseCore is not supported by this target"` 进行 `LOG(FATAL)`，而不是解引用空指针。这就是较老代际不携带 `SparseCoreTarget` 的结构性原因：它们的 `TpuTopology[+0x98]` SparseCore count 为零，门控返回 false，`Target::Init` 从不构建该子对象。

> **注意 —** 该谓词是一个*运行时拓扑*测试，而不是编译时类测试。重新实现必须在任何 SparseCore accessor 可达之前填充其拓扑 descriptor 的 SparseCore-count 字段；否则整个 SC accessor 表面都会 trap。

---

## 标量 Accessor 表面

六个 `Target::SparseCore*` accessor 进入 `Target+0x948`，每个读取一个标量。它们共享相同形状：dispatch `+0x260` 门控，若为 false 则 `LOG(FATAL)`，然后加载 `*(*(this+0x948) + field)`。反编译体确认了基址和每个字段 offset (反编译器将 `Target+0x948` 渲染为 `*((_QWORD *)this + 297)`；`297 × 8 = 0x948`)。

| Accessor | 地址 | 读取 | v7x 值 |
|---|---|---|---|
| `SparseCoreTiles` | `0xFAAFA40` | `[0x948] + 0x90` | 16 |
| `SparseCoreLaneCount` | `0xF7906E0` | `[0x948] + 0x94` | 16 |
| `SparseCoreHbm4bWordSizeBytes` | `0x1320C220` | `[0x948] + 0x58` | 4 |
| `SparseCoreStreamGranuleSizeBytes` | `0x13886EE0` | `[0x948] + 0xA4` | 4 |
| `GetSparseCoreBarrierSyncFlagCount` | `0x10972FA0` | `[0x948] + 0x1D4` | — |
| `SupportsSparseCore` | `0x1D48FD40` | `[0x3B8 TpuTopology] + 0x98 > 0` | true |
| `SparseCoresPerLogicalDevice` | `0x135159C0` | `CoresPerChip / LogicalDevicesPerChip` | 2 |

一个代表性函数体 (`SparseCoreTiles`, `0xFAAFA40`)：

```c
__int64 Target::SparseCoreTiles(Target *this) {
  // vtable +0x260 == *(*this + 608)
  if (!(*(uint8_t (**)(Target *))(*(uintptr_t *)this + 608))(this))
    LOG(FATAL) << "SparseCore is not supported by this target";  // target.h:1704
  return *(uint32_t *)(*(uintptr_t *)(this + 0x948) + 0x90);     // SparseCoreTiles
}

SparseCoresPerLogicalDevice (0x135159C0) 是例外：它完全不读取 [0x948]，而是计算 CoresPerChip(SPARSE_CORE) / LogicalDevicesPerChip。这里包含它，是因为它是运行时调用的入口点 (经由 tensorflow::GetAndSetSparseCoresPerLogicalDevice)，用于确定每设备 SparseCore 数量。

---

Target+0x948 的完整字段布局

该子对象是一个 struct，有两个消费者视图：SC-MLO allocator 视图 (+0x10..+0x54 word/capacity block) 和 HAL/cost-model 视图 (+0x58..+0x1D4)。offset 来自 SparseCoreTarget::Init (0x1D612B20) 的 store site，或来自匹配的 accessor deref。该 struct 至少跨越 0x240 字节；其构造函数被内联，所以析构函数 (0x1D499060) 是一个裸 ret。

Off	类型	字段 / 含义
+0x08	ptr	back-pointer (Target* / core ptr)
+0x10	i32	TIMEM/SCS-sflag capacity (group 0)
+0x14	i32	TAC-sflag capacity (group 1)
+0x18	i32	TEC-sflag / per-tile sflag pool (group 2)
+0x1C	i32	SCS-SMEM capacity (group 0)
+0x20	i32	TAC-SMEM capacity (group 1)
+0x24	i32	TEC-SMEM capacity (group 2)
+0x28	i32	TILE_SPMEM capacity (bytes)
+0x2C	i32	SPMEM capacity (bytes)
+0x30	i32	sparse-core SFLAG capacity
+0x38	i64	HBM 4b-word count = (Target[0x450]+3) >> 2
+0x40	i32	TIMEM/sflag word size (group 0)
+0x44	i32	SMEM word size
+0x48	i32	TILE_SPMEM word size
+0x4C	i32	SPMEM word size
+0x50	i32	TILE-instr (TIMEM) word size
+0x54	i32	per-group word-size slot
+0x58	i32	SparseCoreHbm4bWordSizeBytes = 4
+0x5C..+0x70	i32×N	group-mirrored sflag/smem word sizes + capacities
+0x74	i32	literal 2 (SCS sequencer/group count)
+0x78..+0x8C	i32×N	per-coretype memory counts (TENSOR/SC group fanout)
+0x90	i32	SparseCoreTiles = SequencerCount(5)
+0x94	i32	SparseCoreLaneCount = vector_isa(5).lane_count
+0x98	i32	SC lane bytes = lane_count << 2
+0x9C	i32	SC freq / host-irq block (TpuCoreParts[0x138])
+0xA0	i32	tile_hbm_bandwidth_bytes_per_cycle (cp[0x1E0], gated cp[0x1E8])
+0xA4	i32	stream_granule_size (cp[0x1E4])
+0xA8..+0x238	ptr×N	per-tile reserved-region vectors (SMEM/SPMEM/SFLAG windows)
+0x188	u8	bool flag
+0x190	i64	embedding param-region base word offset
+0x198	u8	bool flag
+0x1D0	i32	SC barrier sync-flag base (SpecialPurposeSyncFlags[0])
+0x1D4	i32	GetSparseCoreBarrierSyncFlagCount (SpecialPurposeSyncFlags[+0x10])
+0x1E8	u8	SparseCore-proto-present flag
+0x1EC..+0x22C	i32×N	compiler-reserved SFLAG watermarks + per-tile reserved-SFLAG block
+0x230/+0x238	ptr×2	tail region vectors
~0x240	—	sizeof(SparseCoreTarget) >= 0x240

陷阱 — +0xA8..+0x238 block 是一串 libc++ vector，持有 per-tile reserved-region descriptor。store offset 已按字节确认，但每个 vector 的元素布局 (它持有哪些 reserved tile region) 没有逐个走查；这些行是 HIGH，而不是 CONFIRMED。

---

Init 几何块

SparseCoreTarget::Init (0x1D612B20) 从 SPARSE_CORE TpuCoreParts 填充几何信息。下面的块是反编译的 store sequence，按字节确认 (反编译器 offset 为十进制；hex 在注释中)：

// SparseCoreTarget::Init @ 0x1D612B20 — geometry block
*(uint32_t *)(sc + 0x58) = 4;                              // SparseCoreHbm4bWordSizeBytes (literal)
*(uint32_t *)(sc + 0x74) = 2;                              // SCS sequencer/group count (literal)
*(uint32_t *)(sc + 0x90) = TpuCoreParts::SequencerCount(cp, 5);   // SparseCoreTiles (seq type 5)
vi = TpuSequencerParts::vector_isa(cp.SequencerParts(5));
*(uint32_t *)(sc + 0x94) = vi.lane_count;                  // SparseCoreLaneCount
*(uint32_t *)(sc + 0x98) = 4 * vi.lane_count;              // SC lane bytes
if (cp[0x1E8] /* SparseCore submsg present */) {
  *(uint32_t *)(sc + 0xA0) = cp[0x1E0];                    // tile_hbm_bandwidth_bytes_per_cycle
  *(uint32_t *)(sc + 0xA4) = cp[0x1E4];                    // stream_granule_size
}
// ... later: barrier sync-flag base + count from a SpecialPurposeSyncFlags sub-object
*(uint32_t *)(sc + 0x1D0) = SpecialPurposeSyncFlags[0];
*(uint32_t *)(sc + 0x1D4) = SpecialPurposeSyncFlags[+0x10];   // GetSparseCoreBarrierSyncFlagCount
```text

tile/lane 几何来自 `TpuCoreParts::SequencerCount(cp, 5)` 和 `SequencerParts(5).vector_isa()`。两个索引都使用*内部* (codec-template) `TpuSequencerType` 编号 `{SCS=3, TAC=4, TEC=5}`，所以索引 `5` 是 `SC_TEC`，即 SparseCore tile-execute 池；在 v7x 上它是 16 实例、`lane_count` 为 16 的 `VectorIsa`。因此 v7x 的 `SparseCoreTiles = 16`、`SparseCoreLaneCount = 16`，与 `6acc60406` SC sequencer 几何的 `chip_parts` 解码一致。

> **注意 —** `Init` 的 `SequencerCount(cp, 5)` / `SequencerParts(cp, 5)` 索引是*内部* `TpuSequencerType` 值，也就是 Part IX SparseCore 页面使用的同一套 codec-template 编号：`{TC=0, BARNA=1, BARNA_ADDR=2, SCS=3, TAC=4, TEC=5}`。在这个方案中，索引 `5 = SC_TEC` (tile-execute 池)，这正是几何块读取的内容；因此 `SparseCoreTiles` / `SparseCoreLaneCount` 来自 TEC sequencer，而不是 TAC。该 enum 的 SparseCore 块是 `{SCS=3, TAC=4, TEC=5}`，也就是规范 wiki 编号；见 [getSequencerType](../sparsecore/getsequencertype.md#the-off-by-one-runtime-enum-vs-codec-template-enum) 和 [SparseCore 概览](../sparsecore/overview.md)。
>
> **怪癖 —** 存在两套合法编号方案，彼此相差一，而 `Init` 使用内部方案。*proto* enum `TpuSequencerTypeProto` 前置了一个 `INVALID=0` 槽，并把 SparseCore 块整体加一编号为 `{INVALID=0, TC=1, BARNA=2, BARNA_ADDR=3, SCS=4, TAC=5, TEC=6}`，所以如果读者把 proto 编号应用到 `Init` 的索引，就会把 `5` 误读为 TAC。`tpu::TpuSequencerTypeToProto` (`0x20B36460`) 返回 `internal + 1`，`tpu::TpuSequencerTypeFromProto` (`0x20B36300`) 将 proto case *N* 映射为 `internal = N − 1`，所以精确地说 `internal = proto − 1`。索引 `TpuCoreParts` 的代码路径 (这里的 `Init`) 接收内部值；只有序列化 proto 字段和 `TpuSequencerTypeToString` 标签表使用 proto 值。(`6acc60406` / `gfc` 只携带内部 codec params 3 和 5，即 SCS + TEC，没有 TAC，所以在 v7x 上根本没有 TAC sequencer 可与 TEC 混淆。)

---

## 非虚拟 Helper

基类 `SparseCoreTarget` 定义了三个非虚拟 helper，供 SC-MLO allocator 读取。全部按字节确认：

| Helper | 地址 | 函数体 |
|---|---|---|
| `SparseCoreSpmemStripeGranularityBytes` | `0x1D499440` | `return 0x100000020LL;` → `optional<32>` (value `0x20`=32, engaged-flag in high dword) |
| `SparseCoreParamPtrLocationWordOffset(i)` | `0x1D618080` | `return [0x190] - i;` with `CHECK(result >= 0)` |
| `SparseCoreStartReservedSmemWordOffset(i)` | `0x1D618060` | tail-jumps to the above |

这些将字段 `+0x190` 固定为 embedding param-region base word offset：allocator 将 parameter pointer 放在递减 offset `[0x190] - i` 处，并在 underflow 时 fatal (`"Parameter number N causes underflow"`)。

---

## 按代号的 MXU Contracting-Depth 表

MXU contracting 维度是 `Target` 子类中的按代号 C++ 字面量，而不是 `chip_parts` 字段。基类 `Target` 返回 128；只有 `GhostliteTarget` override 为 256。"inherit" 表示子类不 override，使用基类值。每个数值单元都是从具名方法读取的逐字节精确字面量。

| MXU 常量 (CODE) | v2 Jelly | v3 Dragon | v4 Puffer | v5p Viperfish | v6e Ghostlite | v7x 6acc60406 |
|---|---|---|---|---|---|---|
| `MxuContractingSize` | 128 | 128 | 128 | 128 | **256** | **256** |
| `MxuNoncontractingSize` | 128 | 128 | 128 | 128 | **256** | **256** |
| `MxuSparseContractingSize` | 0 | 0 | 0 | 0 | 0 (inherit) | 0 (inherit) |
| `MxuContractingSizeIsDoubled(mode)` | false | false | false | **predicate** | **predicate** | **predicate** |
| └ doubled-mode set (raw GainLatchMode) | — | — | — | {22,23,24,25} | {22,23,24,25} | {22,23,24,25} |
| `MinLmrWidthInColumns` | FATAL | FATAL | FATAL | **8** | **16** | **16** |
| `MaxLmrWidthInColumns` | FATAL | FATAL | FATAL | **128** | **128** | **128** |

> **注意 —** v7x `6acc60406` 复用 `GhostliteTarget` TensorCore 子类；此 build 中不存在单独的 `Tpu7xTarget`/`TpuV7xTarget` 类。v6e/v7 的区别通过 `chip_parts` 数据驱动，因此两者都得到 `MxuContractingSize` = 256。

重新实现者应这样阅读：

- **Contracting depth。** Jellyfish 到 Viperfish 的 systolic MXU reduction depth 是 128，Ghostlite 类 (v6e/v7) 是 256。这与 `chip_parts` 的 `lane_count`=128 正交：proto 携带的是 v7x 的 128-lane *width* 和 `mxu_count`=2；256 是 systolic *row depth* 代码常量。由 128×128 代际上的 FLOPS 关系交叉验证 (peak BF16 = `2 × mxu_count × 128² × frequency_mhz` 在 1% 以内复现 v2/v3/v4)。
- **加倍谓词。** `ViperfishTarget` 和 `GhostliteTarget` 都用**相同**谓词 `(mode - 22) < 4u` override `MxuContractingSizeIsDoubled`，即对 raw `GainLatchMode` ∈ {22,23,24,25} 返回 true。这些索引是 4-bit packed-nibble matmul 模式 (S4/U4)：两个 nibble 打包进一个物理 systolic row，使有效 contracting depth 加倍 (128-row 代际上为 256，Ghostlite 的 256-row 上为 512)。基类始终返回 false；较老代际没有 4-bit MXU 模式。
- **LMR width。** `Min/MaxLmrWidthInColumns` 是 latch-matrix-register column window (staging-register granularity)，与 contracting depth **不同**。它只在带 SparseCore 的代际上定义；基类会 `LOG(FATAL)` `"Unimplemented"`。Jellyfish/Pufferfish 反而暴露较老的 `MxuResultEntries{Pushed,Popped}` result-FIFO 模型。`MxuSparseContractingSize` 在每个代际上都是 0；没有子类 override 它；此 build 中未使用 sparse-MXU contracting。

---

## 每代 SparseCore 存在性与几何

| 代际 | TpuVersionProto | SparseCore? | SparseCoreTarget 类 | Tiles × Lane | MXU contracting |
|---|---|---|---|---|---|
| v2 Jellyfish | 1 | no (BarnaCore) | — | — | 128 |
| v3 Dragonfish | 2 | no (BarnaCore) | — | — | 128 |
| v4 Pufferfish | 3 | no (BarnaCore) | — | — | 128 |
| v5p Viperfish | 4 | yes | `ViperfishSparseCoreTarget` | — × 8 (SC_TEC lane) | 128 |
| v6e Ghostlite | 5 | yes | `GhostLiteSparseCoreTarget` | — × 8 (SC_TEC lane) | 256 |
| v7x `6acc60406` | 6 | yes | `GhostLiteSparseCoreTarget` | 16 × 16 | 256 |
| v4 lite / v5e lite | — | no (TC-only) | — | — | 128 |

`Tiles × Lane` 列显示 `chip_parts` 的 `SC_TEC VectorIsa` lane width；v7x 将其加宽到 16 (并且 `SparseCoreTiles`/`SparseCoreLaneCount` 在 `Init` 后都报告 16)。v5p/v6e 携带较窄的 8-lane TEC。lite dies (`pufferfish_lite`, `viperfish_lite`) 既不携带 BarnaCore，也不携带 SparseCore；它们的 `TpuTopology[+0x98]` SC count 为零，因此 `SupportsSparseCore` 为 false，也不会构建 `SparseCoreTarget`。

---

## 按代际的 SparseCore Capability / Geometry 表

24 个 `SparseCoreTarget` virtual accessor 同时存在于两个具体子类中 (`ViperfishSparseCoreTarget` 用于 v5p，`GhostLiteSparseCoreTarget` 用于 v6e Ghostlite + v7x `6acc60406`)。值是逐字节精确的，并按方法名匹配 (Viperfish vtable 顺序相对 GhostLite 偏移一个槽)。

| `SparseCoreTarget` vfn | Viperfish (v5p) | Ghostlite / 6acc60406 (v6e/v7x) | 来源 (VF / GL) · 置信度 |
|---|---|---|---|
| `FlopsPerSparseCore(fmt∈{1,2})` | 1.0e12 (1 TFLOP/s) | 3.595e13 (35.95 TFLOP/s) | `0x1D49C540` / `0x1D4990A0` |
| └ other fmt | → `Target` vtable `+0x718` | → `Target` vtable `+0x718` | tail-call |
| `SparseCoreTileCrossbarBandwidthRandomAccess` | 29 B/cyc | 29 B/cyc | vtable |
| `SparseCoreTileVectorAluSlotCount(bool)` | 3 | 3 | vtable |
| `SparseCoreHbmAccessLatency` | 418 | 418 | `0x1D49C5C0` / `0x1D499120` |
| `SparseCoreSpmemAccessLatency` | 30 | 30 | `0x1D49C5E0` / `0x1D499140` |
| `TaskRequestStartAccessFunctionArgWordOffset` | 1 | 1 | vtable |
| `TaskRequestStartExecuteFunctionArgWordOffset` | 1 | 1 | vtable |
| `TaskRequestEndExecuteFunctionArgWordOffset` | 0 | 0 | vtable |
| `TraceEnBitOffsetInStreamControl` | 15 | 15 | vtable |
| `SetDoneBitOffsetInStreamControl` | 2 | 2 | vtable |
| `TileLocalStrideOffsetInStreamControl` | 3 | 3 | vtable |
| `IndirectListTypeBitOffsetInStreamControl` | 7 | 7 | vtable |
| `IndirectFilterEnBitOffsetInStreamControl` | 14 | 14 | vtable |
| `SupportsScVdupcntVuniqueWithLaneIds` | **0** | **1** | `0x1D49C7A0` / `0x1D499300` |
| `SupportsScVldVstIdxAdd` | **0** | **1** | `0x1D49C7C0` / `0x1D499320` |
| `SupportsScVar` | 0 | 0 | `0x1D49C7E0` / `0x1D499340` |
| `SupportsScFp8VectorCmp` | 0 | 0 | vtable |
| `SupportsScVmemStream` | 0 | 0 | vtable |
| `SupportsScHbm4bStream` | 1 | 1 | `0x1D49C840` / `0x1D4993A0` |
| `SupportsScLocalSpmemDma` | 1 | 1 | `0x1D49C860` / `0x1D4993C0` |
| `SupportsScBundleCompression` | 0 | 0 | vtable |
| `SupportsScB8VectorMaskPopulationCount` | 0 | 0 | vtable |
| `SupportsScEupOps` | **1** | **1** | `0x1D49C8C0` / `0x1D499420` |
| `SupportsTileSmemDma` | 0 | 0 | vtable |

真正的 Viperfish → Ghostlite/6acc60406 capability 增益正好是两个 bit 加 FLOPS 跳变：

- `SupportsScVdupcntVuniqueWithLaneIds` (0 → 1) — vdupcnt / vunique-with-lane-ids ops。
- `SupportsScVldVstIdxAdd` (0 → 1) — indexed vector load/store with add。
- `FlopsPerSparseCore` 1 TFLOP/s → 35.95 TFLOP/s — 加宽后的 Ghostlite/6acc60406 TEC vector engine。

> **陷阱 —** `SupportsScEupOps` 在 Viperfish 和 Ghostlite/6acc60406 上都返回 **1** (已在 `0x1D49C8C0` 和 `0x1D499420` 验证，二者都是 `return 1`)。它**不是**按代际差异：Extended-Unit-Pipeline ops 在 Viperfish 上也存在，所以不要把它计入 Ghostlite 增益。唯一的 capability-bit 差异就是上面列出的两个。

`FlopsPerSparseCore` 函数体是一个小 dispatcher，在两个子类中形状相同：

```c
// GhostLiteSparseCoreTarget::FlopsPerSparseCore @ 0x1D4990A0
__int64 FlopsPerSparseCore(this, int fmt) {
  if ((uint8_t)(fmt - 1) >= 2u)                       // fmt not in {1,2}
    return (*Target_vtable[+0x718])(this->target, fmt);  // delegate to Target flops
  return /* xmm0 = */ qword_A2DE920;                  // 3.595e13 for fmt in {1,2}
}

对于 matmul data format 1 和 2，它返回 SparseCore-local FLOPS 常量；对于其他一切，它尾委托给 vtable 槽 +0x718 处的 Target per-format FLOPS。Viperfish 具有相同结构，只是常量位于 qword_A2DFD18 (1.0e12)。

---

相关组件

名称	关系
Target::Init	通过 SparseCoreTarget::Init 构建 unique_ptr<SparseCoreTarget>，并将其安装在 Target+0x948
SparseCoreTarget::Init (0x1D612B20)	从 SPARSE_CORE TpuCoreParts 填充每个字段
xla_mlo_util::CapacityInBytes / WordSizeInBytes	SC-MLO allocator，是 +0x10..+0x54 capacity/word block 的消费者
GhostliteTarget / ViperfishTarget	携带 MXU-256 / LMR-width 字面量的 TensorCore Target 子类

交叉引用

• 按代号常量 — 这个 descriptor 的几何所依据解码的、来源于 chip_parts 的按代际 memory/MXU/core-count 表
• TpuChipConfig — 按代号常量如何组装成运行时 Target 配置
• SparseCore 概览 — 这些 capability bit 和 stream-control offset 所馈入的 SCS/TAC/TEC 引擎模型
• SC ↔ MXU 握手 — MxuContractingSize、加倍谓词和 LMR-width window 的消费者