PCIe 参考时钟架构 (Refclk Architecture)

简介: PCIe 参考时钟架构 (Refclk Architecture)

开聊之前先梳理几个概念:


  •    Jitter,时钟抖动,是对于同一 Clock 而言的, 是时钟源引起的,用来描述被测时钟与理想时钟在时域的偏差(单位为 ps RMS,皮秒均方根)。


  •    Skew,时钟偏斜,是对于多个时钟线而言的,是时钟树不平衡引起的。


  •    此外还有一个概念是频率稳定性,用来描述被测时钟频率与理想时钟频率的偏差(单位 ppm,百万分之一)。




参考时钟


PCIe Serdes 在时钟驱动下收发串行数据流。Serdes 所用时钟由 PHY 内的 PLL 生成,PLL 的参考时钟由外部提供或从接收数据流中恢复出来。


 PCIe 协议指定标准的参考时钟为 HCSL 电平的 100 MHz 时钟,Gen1~Gen4 下要求收发端参考时钟精度在 ±300 ppm 以内,Gen5 要求频率稳定性 ±100 ppm。在 FPGA 应用中,为了兼顾其他 IP,采用 LVCMOS/LVDS/LVPECL 电平 125 MHz/250 MHz 的方案也较为常见。



时钟架构


PCIe 时钟架构是指 PCIe 系统中收发端设备给定参考时钟的方案。PCIe 有 3 种时钟架构(图 1),分别为:Common Clock Architecture (CC),Separate Clock Architecture 和 Data Clock Architecture。


3376a701b08d42f98ca889935bfe644c.png


Common Clock Architecture


Common Clock Architecture (CC),通用参考时钟架构,收发端共享同一个参考时钟。三种 PCIe 参考时钟架构中,Common Clock 是最为常用的一种时钟架构,采用 Common Clock 支持时钟扩频(SSC, Spread Spectrum Clock) 且对参考时钟的要求不如 Separate Clock 方案严苛。Common Clock 对于频率稳定性的要求是 ±300 ppm。


对于适用同一 Common Clock 作为参考时钟的 PCIe 设备,所有设备间的时钟偏斜(Clock Skew)必须保持在 12 ns 以内,这无疑对大型电路板上或跨板的 PCIe 设备间布局布线形成巨大挑战。




Separate Clock Architecture


Separate Clock Architecture,收发端采用独立的参考时钟,根据有无 SSC 可进一步分为 SRNS ( Separate Refclk with No SSC) 及 SRIS (Separate Refclk with Independent SSC)。


 对于收发端采用独立参考时钟的方案,其收发端独立使用不同的参考时钟源,无需单独传递时钟,对布局布线的要求更宽松。SRNS 允许 ±300 ppm (600ppm),而 SRIS 允许 ±2800 ppm (5600 ppm,其中SSC允许 5000ppm,TX/RX允许 600 ppm)。


 若 PCIe 设备开启了 SRIS,其发生 SKP 的频率应该加大,同时加大弹性缓存(Elastic Buffer)的深度。弹性缓存加大使得延时更大,在一定程度上降低了 performance。对于一条 PCIe 链路,如何知道要不要采用 SRIS 呢?遗憾的是,目前尚没有机制实现收发端之间的 SRIS 协商。



Data Clock Architecture


Data Clock Architecture,仅发送端需要 Refclk,接收端无需外部 RefClk,其 CDR (Clock Data Recovery,时钟数据恢复)的 Refclk 参考时钟从数据流中恢复出来。Data Clock 时钟方案是三种方案中最易实现的方案,其无需外部参考时钟,在数据流中携带有时钟信息,接收端接收数据流并从中恢复出时钟供给其 CDR 作参考时钟。


Data Clock 时钟方案仅适用于 Gen2 及 Gen3,单 lane 单向最高速率 8GT/s。




扩频时钟(SSC)


扩频时钟可以抑制电磁干扰(EMI)。为了降低 PCIe 时钟及数据线的电磁辐射、增强高速数据传输可靠性,PCIe 时钟可以采用 SSC 对参考进行时钟扩频。Gen1~Gen5 都支持 SSC,但只有 Gen3 及以上支持 SRIS。


 PCIe 扩频模式为向下扩频,扩频范围为-0.5%~0%,确保最大频率在标称频率之下。最大调制幅度为 -0.5%!


 调制频率为 30 KHz ~ 33 KHz,确保 PLL 能够跟得上,同时减小音频噪声的引入。调制波形采用三角波,该波形易于实现,且调制后的频谱接近均匀分布。


 注意:30 KHz ~ 33 KHz 是指频率随时间周期变化的频率,不是展宽的带宽,带宽为时钟频率的 0.5% 。


 更多扩频相关介绍,请查看文末参考资料。




Clock Jitter


Common Clock 与 Data Clock Jitter


 随着 PCIe 速率的提升,其对时钟抖动 (Jitter) 的要求也越来越严苛。图 2 为 Common Clock 及 Data Clock 模式下的不同 PCIe 速率对 Jitter 的要求。

5e66077e4b654f279d64436bde968f86.png

▲ 图 2 Common Clock 及 Data Clock 架构的 Jitter 需求





SRNS/SRIS Clock Jitter



目前尚未出台 SRNS/SRIS 模式下 Gen4/Gen5 的 Jitter Limit,现有的 SRNS/SRIS Jitter Limit 是基于 Common Clock Jitter Limit 等效推算出来的。


 假设 Separate Clock 收发端采用跟 Common Clock 相同电平、相同 Jitter 、相同频率的时钟。设 Common Clock 系统 Jitter Limit 为 J C C S y s t . S i m J_{CC_{Syst.Sim}} JCCSyst.Sim(仿真结果,非标准指定),那么采用 Separate Clock 的方案,引入了两个随机独立的 Jitter J 1 J_1 J1 和 J 2 J_2 J2(图3)。系统总的 Jitter 可以表示为两者平方和的根,即:


JT=J12+J22


假设 J 1 = J 2 = J S R N S , S R I S J_1=J_2=J_{SRNS,SRIS} J1=J2=JSRNS,SRIS, Separate Clock 要达到跟 Common Clock 相同的系统 Jitter Limit J C C S y s t . S i m J_{CC_{Syst.Sim}} JCCSyst.Sim, 其收端或发端 Clock Jitter Limit 可以表示为:



JSRNS,SRISMAX=JCCSyst.Sim/2



e283b1eb846b42e3b1d3a0dfc7d8bc20.png


▲ 图 3 Separate Reference Architecture Jitter Distribution

a2f6b86562934b16b79c8d2969805b5c.png


▲ 图 4 Separate Clock 架构的 Jitter 需求


 图4 是基于 Common Clock 架构计算出的 SRNS/SRIS Jitter Limit。整体来看,Separate Clock 的 Jitter Limit 比 Common Clock 和 Data Clock Jitter Limit 都要小,也就是说Separate Clock 对Clock Jitter 的要求更为严苛。


 注意:Common Clock 及 Data Clock 时,考虑到长距离时钟线上的耦合噪声,标准中给定的 Limit 是要比仿真结果小的,比如系统仿真 Gen5 的 Clock Jitter Limit 是0.25 ps RMS,标准中给定的是 0.15 ps RMS。但采用 Seoparate Clock 架构的 PCIe 系统,其收发端各自有一个独立的时钟源,消除了时钟线的耦合噪声,其 Jitter Limit 仍采用仿真结果。




参考


  1.    PCI Express Base 6.0,Chapter 4.3.9 & 8.6


  1.    关于PCIe参考时钟的讨论


  1.    PCIe 的时钟结构


  1.    Selecting the Optimum PCI Express Clock Source


  1.    进行精准的PCIe 4.0时钟抖动测量


  1.    PCIe Separate Reference Clock With Independent Spread (SRIS) Architecture Overview


  1.    PCIe Spread Spectrum Clocking (SSC) for Verification Engineers
  2.    什么是SSC(扩频时钟)


  1.    采用扩频技术的EMI解决方案


  1.    扩频时钟SSC技术,即展频


  1.    高速协议时钟SSC扩频展频学习整理


  1.    时钟抖动计算






目录
相关文章
|
7月前
|
SQL 前端开发 关系型数据库
如何开发一套研发项目管理系统?(附架构图+流程图+代码参考)
研发项目管理系统助力企业实现需求、缺陷与变更的全流程管理,支持看板可视化、数据化决策与成本优化。系统以MVP模式快速上线,核心功能包括需求看板、缺陷闭环、自动日报及关键指标分析,助力中小企业提升交付效率与协作质量。
|
7月前
|
JSON 文字识别 BI
如何开发车辆管理系统中的加油管理板块(附架构图+流程图+代码参考)
本文针对中小企业在车辆加油管理中常见的单据混乱、油卡管理困难、对账困难等问题,提出了一套完整的系统化解决方案。内容涵盖车辆管理系统(VMS)的核心功能、加油管理模块的设计要点、数据库模型、系统架构、关键业务流程、API设计与实现示例、前端展示参考(React + Antd)、开发技巧与工程化建议等。通过构建加油管理系统,企业可实现燃油费用的透明化、自动化对账、异常检测与数据分析,从而降低运营成本、提升管理效率。适合希望通过技术手段优化车辆管理的企业技术人员与管理者参考。
|
7月前
|
消息中间件 缓存 JavaScript
如何开发ERP(离散制造-MTO)系统中的生产管理板块(附架构图+流程图+代码参考)
本文详解离散制造MTO模式下的ERP生产管理模块,涵盖核心问题、系统架构、关键流程、开发技巧及数据库设计,助力企业打通计划与执行“最后一公里”,提升交付率、降低库存与浪费。
|
6月前
|
前端开发 JavaScript BI
如何开发车辆管理系统中的车务管理板块(附架构图+流程图+代码参考)
本文介绍了中小企业如何通过车务管理模块提升车辆管理效率。许多企业在管理车辆时仍依赖人工流程,导致违章处理延误、年检过期、维修费用虚高等问题频发。将这些流程数字化,可显著降低合规风险、提升维修追溯性、优化调度与资产利用率。文章详细介绍了车务管理模块的功能清单、数据模型、系统架构、API与前端设计、开发技巧与落地建议,以及实现效果与验收标准。同时提供了数据库建表SQL、后端Node.js/TypeScript代码示例与前端React表单设计参考,帮助企业快速搭建并上线系统,实现合规与成本控制的双重优化。
|
7月前
|
消息中间件 JavaScript 前端开发
如何开发ERP(离散制造-MTO)系统中的技术管理板块(附架构图+流程图+代码参考)
本文详解ERP(离散制造-MTO)系统中的技术管理板块,涵盖产品定义、BOM、工序、工艺文件及变更控制的结构化与系统化管理。内容包括技术管理的核心目标、总体架构、关键组件、业务流程、开发技巧与最佳实践,并提供完整的参考代码,助力企业将技术数据转化为可执行的生产指令,提升制造效率与质量。
|
7月前
|
监控 供应链 前端开发
如何开发ERP(离散制造-MTO)系统中的财务管理板块(附架构图+流程图+代码参考)
本文详解离散制造MTO企业ERP系统中财务管理模块的搭建,聚焦应收账款与应付账款管理,涵盖核心功能、业务流程、开发技巧及Python代码示例,助力企业实现财务数据准确、实时可控,提升现金流管理能力。
1035 32
|
7月前
|
供应链 监控 JavaScript
如何开发ERP(离散制造-MTO)系统中的库存管理板块(附架构图+流程图+代码参考)
本文详解MTO模式下ERP库存管理的关键作用,涵盖核心模块、业务流程、开发技巧与代码示例,助力制造企业提升库存周转率、降低缺货风险,实现高效精准的库存管控。
|
7月前
|
前端开发 API 定位技术
如何开发车辆管理系统中的用车申请板块(附架构图+流程图+代码参考)
本文详细解析了如何将传统纸质车辆管理流程数字化,涵盖业务规则、审批流、调度决策及数据留痕等核心环节。内容包括用车申请模块的价值定位、系统架构设计、数据模型构建、前端表单实现及后端开发技巧,助力企业打造可落地、易扩展的车辆管理系统。
|
7月前
|
消息中间件 JavaScript BI
如何开发ERP(离散制造-MTO)系统中的客户管理板块(附架构图+流程图+代码参考)
本文详解离散制造-MTO模式下ERP系统客户管理模块的设计与实现,涵盖架构图、流程图、功能拆解、开发技巧及TypeScript参考代码,助力企业打通客户信息与报价、生产、交付全链路,提升响应效率与订单准交率。
|
7月前
|
JSON 前端开发 关系型数据库
如何开发ERP(离散制造-MTO)系统中的销售管理板块(附架构图+流程图+代码参考)
针对离散制造MTO模式,销售管理是业务核心入口,贯穿报价、订单、ATP、排产与交付。本文详解其架构设计、关键流程、数据模型及开发实践,助力企业提升交付准确率与运营效率。
下一篇
开通oss服务