在 PCIe 总线中，虽然架构高度优化，支持分层流水处理，但仍然可能出现“死锁”现象，尤其在复杂拓扑、错误的协议实现或资源饱和场景中。下面详细解释 PCIe 总线中可能出现死锁的原因、类型及应对机制。

---

✅ 什么是 PCIe 总线的“死锁”？

死锁是指：多个 PCIe 设备或桥接器在等待彼此释放资源，结果所有通路都阻塞，通信无法前进，永远处于等待状态。

---

🧠 常见死锁场景与成因

🔹 场景一：Credit-based 流控死锁

机制：PCIe 是 credit-based flow control —— 发 TLP 要扣 credit，收完才能归还。

死锁原因：

情况	描述
A 设备等待 credit 才能发送 Completion TLP
B 设备又在等待 A 的 Completion 作为响应
A 和 B 都不再发 Flow Control Update ⇒ 僵持住了

本质是：设备都等对方释放 credit，结果 credit 永远不释放。

---

🔹 场景二：Posted/Non-Posted starvation 导致 pipeline 卡死

PCIe 有 Posted、Non-Posted、Completion 三种事务队列，某些桥或设备实现不规范时会：

• 过度优先发送某类事务（如只发 Memory Write，不发 Completion）
• 导致对端 buffer 被塞满，Flow Control 无法返回

📌 导致：TLP 队列阻塞 ⇒ 无法发送新的 TLP ⇒ 阻塞反馈 ⇒ 死锁

---

🔹 场景三：内部依赖循环（例如 Root Port + Switch）

在复杂拓扑中（例如 RC ←→ Switch ←→ 多EP），一种死锁可能为：

1. RC 发起 Memory Read 请求（Non-Posted）
2. EP 需要先发 Memory Write 才能响应（但没有 credit）
3. Switch 内部路由器或缓冲区对不同 TLP 类型处理不合理
4. 所有路由通路都被 Posted TLP 塞满，但没有 Flow Control Update 被发出

==> 整个数据流 pipeline 停住

---

🔹 场景四：软件控制错误（中断/寄存器读写死锁）

1. 软件等待设备寄存器状态更新（Polling）
2. 设备必须收到 host 的写入才能更新状态
3. 双方都卡在状态等待上 ⇒ 软件层死锁

---

✅ PCIe 设计中如何避免死锁

手段	描述
💧 合理分配 TX/RX Buffer 和 Credit	不同 TLP 类型分配独立通道（避免 starvation）
🧠 采用 Round-Robin 调度策略	保证 Posted/Non-Posted/Completion 都能周期性发出
🔁 完整实现 Flow Control Update	避免 credit 归还失效
⛔ 限制 Outstanding Non-Posted Requests	控制 Read 请求深度
🧪 验证阶段模拟极限条件	使用 PCIe 验证工具插入繁忙或死锁场景

---

✅ PCIe规范中有关“死锁”或“流控饥饿”的规定

• PCIe Base Spec 明确规定：

  • Completion TLP 必须能优先处理，防止长时间阻塞
  • 每个 Layer 必须能响应 Flow Control Update
  • Root Port、Switch 必须支持多通道、类型隔离
  • 软件应避免同时等待多个未完成的 Read TLP 而无响应机制

---

🎯 总结

死锁类型	典型表现
Credit死锁	双方都等对方归还 credit
Queue starvation	事务类处理不均衡，造成流阻塞
Switch死锁	多路径互相等待
软件死锁	软件与设备轮询/中断处理出错

🧠 PCIe 本身协议设计良好，真正死锁大多出现在硬件实现错误或异常使用场景。

---