📚 课程目录第3章硬件平台搭建与测量环境

3. 硬件平台搭建与测量环境

在 Ryzen Embedded 平台上做性能与功耗优化，测量环境本身往往比优化动作更容易出错。一个不可复现的测量环境，会让后续所有调参结论失去意义。本节围绕“选板—供电—散热—功耗测量—温度采集—软件监控”这条链路，说明如何搭建一套可信、可复现的测量平台。

开发板选型：先看测量能力，再看算力

Ryzen Embedded 常见型号包括 V1000、V2000、R1000、R2000 系列，以及面向高算力的 V3000 系列。选板时不要只比较 CPU 核心数和 TDP，而应优先确认以下与测量直接相关的条件：

功耗测量点：板卡是否提供 12V/19V 主输入的分流电阻或电流检测排针。若只能测整机墙插功耗，就无法区分 SoC 与外围（NVMe、网卡、风扇）的功耗占比。
温度传感器：是否暴露 Tctl/Tdie、SoC 供电区、内存、NVMe 的传感器读数。缺少 Tdie 时，只能依赖外壳温度，响应滞后严重。
散热接口：是否预留标准 4pin PWM 风扇接口和散热器安装孔位，便于替换不同散热方案做对比。
可调功耗接口：是否支持通过 BIOS 或 SMU 工具设置 PPT（Package Power Target）、TDP、STAPM 等参数。
扩展与复现性：是否有稳定的固件版本、可固定频率的选项，避免不同批次板卡引入偏差。

教学示例中，我们假设选用一块 V2000 系列开发板，标称 TDP 15W，提供 12V DC 输入、板载 INA226 电流检测芯片、Tdie 传感器和 4pin PWM 风扇接口。这些条件决定了后续测量方案的上限。

电源：稳定、可测、可调

电源是功耗测量的第一环。推荐使用可编程直流电源，而非普通适配器，原因有三：一是可以精确设定输入电压（如 12.0V），排除适配器压降带来的偏差；二是可以读取输入电流，作为功耗计的交叉验证；三是可以在测试中模拟欠压、过压等边界条件。

接线时要注意：电源输出先经过功耗计，再接入开发板主输入。功耗计应选择支持高侧分流、采样率不低于 1kHz 的型号，例如 INA226 或 INA260 方案。若使用板载检测芯片，需确认其分流电阻阻值和增益，避免量程溢出。教学示例中，分流电阻取 5mΩ，最大量程约 16A，足以覆盖 V2000 的峰值电流。

测量前先用电子负载或已知功率电阻校准功耗计，记录零点漂移。零点漂移超过 10mA 时，低功耗场景（如 idle 状态）的读数将不可信。

散热：把散热方案当作变量而非背景

散热直接决定 SoC 能否维持高频，也决定功耗读数的稳定性。搭建测量环境时，散热方案应作为可替换变量，而不是固定背景。常见方案包括：

被动散热：无风扇，依赖散热片和机箱气流，适合低功耗场景，但长时间负载下会触发降频。
主动风冷：4pin PWM 风扇，可通过转速控制做对比实验。
水冷或半导体制冷：用于极限测试，但引入额外功耗，需单独计量。

教学示例中，我们固定使用同一款 40mm PWM 风扇，转速设为 3000RPM 和 6000RPM 两档，分别记录 Tdie 和频率变化。散热器安装时需保证硅脂涂抹均匀、压力一致，否则接触热阻差异会掩盖优化效果。

温度采集：区分 Tctl、Tdie 与板级传感器

Ryzen Embedded 的温度读数主要有三类：Tctl 是控制温度，通常带有偏移量；Tdie 是真实结温；板级传感器（如 NCT 系列）读取的是 SoC 供电区和内存附近温度。做功耗优化时，应以 Tdie 为准，Tctl 仅用于风扇控制策略参考。

采集方式上，Linux 下可通过 k10temp 驱动读取 Tdie，通过 lm-sensors 读取板级传感器。采样周期建议设为 100ms～500ms，过密会引入额外 CPU 开销，过疏会丢失瞬态峰值。

软件监控工具链：从采集到记录

软件监控需要同时覆盖功耗、温度、频率、利用率和风扇转速。推荐组合如下：

功耗：ina226 或 ina260 内核驱动，通过 sysfs 读取电压、电流、功率。
温度：k10temp + lm-sensors，读取 Tdie 和板级温度。
频率与利用率：cpupower、turbostat 或 perf，记录每核频率和 C-state 驻留。
风扇：pwmconfig 或直接写 sysfs 的 pwm1 节点。
记录：用 sar、collectd 或自定义脚本，将上述数据按统一时间戳写入 CSV。

下面给出一个最小可用的采集脚本示例，每 200ms 记录一次功耗、Tdie 和频率：

#!/bin/bash
OUT=measure_$(date +%Y%m%d_%H%M%S).csv
echo "timestamp,power_mW,temp_mC,freq_MHz" > $OUT
while true; do
  P=$(cat /sys/class/power_supply/ina226/power_now 2>/dev/null || echo 0)
  T=$(cat /sys/class/hwmon/hwmon*/temp1_input 2>/dev/null | head -1)
  F=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
  echo "$(date +%s%3N),$P,$T,$((F/1000))" >> $OUT
  sleep 0.2
done

脚本运行后，用 stress-ng --cpu 4 --timeout 60s 施加负载，观察 CSV 中功耗与 Tdie 的爬升曲线。若功耗在 30 秒内达到平台期而 Tdie 仍在上升，说明散热尚未饱和，需延长测试时间或提高风扇转速。

测量环境验证：先做一次基线测试

环境搭好后，不要直接进入优化实验，先做一次基线测试。步骤如下：

系统空载运行 5 分钟，记录 idle 功耗和 Tdie，确认读数稳定。
用 stress-ng --cpu 4 --timeout 120s 施加满载，记录功耗峰值、Tdie 峰值和频率维持情况。
对比功耗计读数与电源读数，偏差应小于 3%。若偏差过大，检查分流电阻和接线。
记录风扇转速与 Tdie 的对应关系，确认散热方案在满载下不会立即触发降频。

教学示例中，基线测试可能得到如下结果：idle 功耗约 4.2W，Tdie 约 42°C；满载 120 秒后功耗稳定在 14.8W，Tdie 约 78°C，频率维持在 2.8GHz 左右。这些数值仅用于说明观察方式，实际结果会因板卡、散热和环境温度不同而变化。

若满载功耗远低于 TDP 标称值，先检查是否触发了 STAPM 或温度墙，而不是急于调整 PPT。测量环境的问题往往伪装成“优化效果”。

完成上述步骤后，你就拥有了一套可复现的测量平台：电源可调、功耗可测、温度可读、散热可控、数据可记录。后续所有性能与功耗优化实验，都应在这套平台上进行，并保留原始 CSV 数据以便回溯。