3. 可靠性指标体系与任务剖面
在把可靠性要求落到 PolarFire FPGA 设计之前，必须先建立一套可量化、可分解、可验证的指标体系。工程上最常用的三个顶层指标是 FIT、MTBF 和可用性，它们分别回答“失效率有多高”“平均能撑多久”“系统真正可用的比例是多少”。而这三个指标能否成立，取决于一个前提——任务剖面是否被正确定义。
一、FIT、MTBF 与可用性的定义与换算
FIT（Failures In Time）表示每 10⁹ 器件小时内的失效次数，即 1 FIT = 1 次失效 / 10⁹ 小时。它描述的是瞬时失效率 λ，适合描述元器件级、板级乃至系统级的随机失效强度。例如某器件在 55 ℃、50% 电应力下 λ = 20 FIT，意味着平均每 5×10⁷ 小时出现一次失效。
MTBF（Mean Time Between Failures）是平均无故障时间，对恒定失效率模型有 MTBF = 1/λ。若 λ = 20 FIT = 20×10⁻⁹ /h，则 MTBF = 5×10⁷ h ≈ 5708 年。这个数字看似夸张，但它只反映随机失效，不代表产品寿命，也不包含磨损型失效。
可用性 A 描述系统在需要时处于可工作状态的概率，稳态下 A = MTBF / (MTBF + MTTR)，其中 MTTR 为平均修复时间。可见可用性同时受失效率和修复能力影响：即使 MTBF 很高，若 MTTR 很长，可用性仍会下降。
换算示例（示例参数，非实测）：某 PolarFire 板卡 λ = 200 FIT，MTTR = 8 h。
MTBF = 1 / (200×10⁻⁹) = 5×10⁶ h；
A = 5×10⁶ / (5×10⁶ + 8) ≈ 0.9999984，即约 99.99984%。
二、任务剖面：指标成立的前提
任务剖面（Mission Profile）是对产品全生命周期内所经历的工作状态、环境条件和时间占比的结构化描述。它通常包含：任务阶段（如地面待机、发射/上电、正常工作、降级运行、关机）、各阶段持续时间与循环次数、温度与温度变化率、电源电压波动、振动与冲击、湿度与辐照等。没有任务剖面，FIT 和 MTBF 就失去了应力基准，指标无法比较也无法分解。
对 PolarFire 而言，任务剖面至少应明确：结温 Tj 的范围与分布、核心电压与 I/O 电压的允许偏差、上电/掉电循环次数、配置刷新频率、以及是否处于高辐照环境。这些量直接决定后续的降额系数和失效率模型选择。
三、环境应力条件与失效率模型
工程上常用 Arrhenius 模型描述温度对失效率的加速作用：λ(T) = λ₀ × exp[(Ea/k)(1/T₀ − 1/T)]，其中 Ea 为激活能（示例取 0.7 eV），k 为玻尔兹曼常数 8.617×10⁻⁵ eV/K，T 为绝对温度。电压应力则常用电压加速因子描述。把这些因子与任务剖面中各阶段的时间占比加权，就得到任务剖面上的等效失效率。
例如某 PolarFire 器件在 40 ℃ 基准下 λ₀ = 15 FIT，任务剖面中 70% 时间处于 40 ℃、30% 时间处于 85 ℃。85 ℃ 相对 40 ℃ 的加速因子约为 exp[(0.7/8.617×10⁻⁵)(1/313 − 1/358)] ≈ 26。则加权失效率约为 15×(0.7 + 0.3×26) ≈ 127.5 FIT。这说明高温阶段虽短，却可能主导整体失效率。
四、指标分解到 PolarFire 设计约束
顶层指标必须逐层分解为可执行的设计约束，否则无法在 RTL、约束文件和布局布线中落地。分解路径通常为：系统可用性 → 系统失效率预算 → 板级/器件级 FIT 预算 → PolarFire 内部资源与功能模块的失效率分配 → 具体设计约束。
对 PolarFire 设计，可落地的约束包括：
- 结温约束：根据任务剖面最高环境温度与散热能力，设定 Tj 上限（如工业级 100 ℃），并在 SmartTime 中约束时序余量，避免高温下时序违例。
- 降额约束：核心电压、I/O 电压、时钟频率、逻辑利用率均按降额准则设定上限，例如逻辑利用率不超过 70%，以降低电应力和局部热点。
- 冗余与纠错：对高可靠路径使用 TMR 或双模冗余；对配置存储器启用 SEU 免疫配置单元或定期刷新，以应对辐照环境。
- 监控与恢复：集成温度监控、电压监控和看门狗，配合 MTTR 目标设定故障检测与恢复时间。
- 验证约束：把 FIT 预算转化为可测试项，如高温老化、电压拉偏、配置刷新测试，并记录失效模式用于反馈修正。
下面用一张关系图展示从任务剖面到 PolarFire 设计约束的分解链路，以及各指标之间的换算关系。
五、把指标写进设计流程
实际项目中，建议把上述分解结果固化为一份可靠性约束表，随设计版本一同维护。表中至少包含：任务剖面阶段、对应环境应力、分配到的 FIT 预算、PolarFire 内部模块、设计约束值、验证方法。每次 RTL 或约束变更后，重新核算加权失效率，确认仍满足顶层可用性目标。这样，FIT、MTBF、可用性就不再是报告里的数字，而是贯穿 PolarFire 设计、约束、验证全过程的工程依据。