解读

国内SoC面试中，一旦简历出现“通信基带”“5G PHY”“Wi-Fi/BT”等关键词，面试官就会追问“吞吐量怎么验”。
他真正想确认的是：

1. 你是否把“吞吐量”定义为“信息比特率”而非“线速率”；
2. 能否在UVM环境里把“吞吐”这一性能指标转成可量化、可回归、可sign-off的验证项；
3. 是否理解信道编解码（FEC+交织+速率匹配）对吞吐量的制约，并能把瓶颈拆成“算法极限”“微架构”“接口反压”三层来验。
   回答要体现“指标量化→激励构造→监测→结果判定→覆盖率”完整闭环，否则会被认为是“只跑过波形”。

知识点

1. 吞吐量定义

   • 信息吞吐 Tp = 正确译码的 info_bit / 耗时，单位 Mbps；
   • 与线速率区别：需去掉包头、导频、填充、重传冗余；
   • 分“峰值吞吐”“持续吞吐”“最差块长吞吐”三档，国内项目普遍要求三档全部sign-off。

2. 编解码模块的吞吐瓶颈

   • 算法层：码率、迭代次数、early-termination概率；
   • 微架构层：并行度、流水线级数、SRAM读写带宽、AXI反压；
   • 系统层：DMA通道数、DDR带宽、中断延迟。

3. 验证IP选型

   • 参考模型：C++/SystemC golden，必须bit-exact且带统计接口；
   • 速率适配：在UVM sequence里用real-time clock或抽象cycle-count两种模式；
   • 时序检查：SVA断言“译码valid间隔≤N cycle”作为性能契约。

4. 性能监测

   • 在uvm_monitor中内嵌perf_probe，采集info_valid、block_len、start_of_frame、end_of_frame四信号；
   • 用uvm_tlm_analysis_port把原始事件送进uvm_scoreboard，由scoreboard计算滑动窗口吞吐；
   • 窗口大小取“最大CB（code block）+ 保护间隔”，防止毛刺。

5. 结果判定

   • 阈值表来自算法组：峰值≥理论值×0.95，持续≥0.9，最差块长≥0.85；
   • 用uvm_objection控制测试结束条件：连续1 ms无吞吐跌落；
   • 一旦低于阈值，自动dump波形、寄存器、RAM内容，定位是“迭代超时”还是“AXI反压”。

6. 覆盖率

   • 性能覆盖率：码率×块长×SNR×early-termination_en 四维多值覆盖；
   • 功能覆盖率：保证“高吞吐场景”与“误码平台”同时被验到，防止“只跑happy path”。

答案

步骤化描述，可直接用于面试口语：

1. 在验证计划里把吞吐量拆成三档指标，并和算法组确认理论上限；
2. 搭建dual-top环境：
   • 一端接参考模型，输出info_bit计数；
   • 一端接RTL，用同一份激励，在monitor里采集译码完成事件；
3. 在scoreboard里开1 ms滑动窗口，计算Tp=info_bit/window_time，实时与阈值比较；
4. 用constraint random在sequence里随机化：码率、块长、SNR、early-termination使能、AXI延迟、DDR带宽占用，确保“高负载+坏信道”组合被命中；
5. 加SVA断言：valid间隔大于N cycle即报警，直接定位流水线 stall；
6. 回归阶段把吞吐跌落事件映射到“功能-性能”联合覆盖率，未覆盖到的组合手动补定向case；
7. 最终sign-off报告给出三档最差裕量、0 ppm跌落记录、覆盖率100%，并附“瓶颈-优化”列表供后端做时钟/复位/布局参考。

拓展思考

1. 若芯片支持HARQ，需要把“重传合并”带来的吞吐抖动也量化：可在scoreboard里引入“有效比特率”= 传输比特 / (首传+重传时间)，并验“重传次数≤2时有效比特率下降≤8 %”的契约。
2. 国内项目常把“功耗-吞吐”做成联合向量，验证时可把perf_probe的吞吐事件实时送进power tracker，检查“峰值吞吐场景下动态功耗≤预算”是否成立，提前避免“性能达标却过热”的流片风险。
3. 对于PCIe或以太网封装场景，需验证“拆包/组包”开销：在monitor里把packet header去掉后再算info_bit，防止“线速率虚高”误导系统架构。