-
摘要:
作为摩尔定律的“破局者”，Chiplet技术被业界寄予了厚望. Chiplet技术能够将多个具有特定功能的“小芯粒”通过高速互联技术组合成一个“小芯粒”集成芯片，其技术核心是能够实现芯粒组合扩展的芯粒互联技术. 从Chiplet互联协议、互联架构、典型互联芯粒、基于互联芯粒的可测性设计几个方面进行了分析与讨论. 首先详细对比分析了国内外Chiplet互联协议，给出了各协议的分层及功能. 然后介绍了3种典型的Chiplet互联架构，分析了各种架构的特点及优势. 之后介绍了Chiplet容错机制，介绍了互联接口容错编码、容错拓扑和容错路由等容错途径. 接着给出了可编程互联芯粒、路径可编程互联芯粒以及专用互联芯粒3种设计方案. 最后介绍了基于互联芯粒的可测试性设计与测试方案. 以Chiplet互联为主题，旨在帮助读者对芯粒互联技术进行系统性了解.
Abstract:As the breaker of Moore’s Law, Chiplet technology has high expectations in the integrated circuit industry. Chiplet technology can combine multiple small chips with specific functions into a Chiplet integrated chip through high-speed interconnection technology, whose core technology is the Chiplet interconnection technology that can achieve Chiplet combination and expansion. This paper analyzes and discusses the Chiplet interconnection protocol, interconnection architecture, typical interconnection Chiplets, and testability design based on the interconnection Chiplet. Firstly, this paper provides a detailed comparison and analysis of domestic and foreign Chiplet interconnection protocols, and provides the layers and functions of each protocol. Secondly, this paper introduces three typical Chiplet interconnection architectures, and analyzes the characteristics and advantages of each architecture. Afterwards, the Chiplet fault-tolerant mechanism is introduced, including fault-tolerant encoding of interconnection interfaces, fault-tolerant topology, and fault-tolerant routing. Then, three types of interconnection Chiplet design schemes are presented, including programmable interconnection Chiplets, path programmable interconnection Chiplets, and fully customized interconnection Chiplets. Finally, a testability design testing scheme based on the interconnection Chiplet is introduced. This paper focuses on Chiplet interconnection and aims to help readers help readers have a systematic understanding of Chiplet interconnection technology.
-
Keywords:
- Chiplets /
- interconnection /
- interconnection Chiplets /
- architecture /
- fault tolerance /
- design for testability
-
近年来，更多具有严格要求的应用场景展现出对网络无丢失特性的需求. 例如，在大规模分布式存储业务中，丢包后的数据块重传会占据大量可用带宽，长时间超时可能导致传输几乎停止[1]. 在高性能计算（high performance computing，HPC）应用中，进程间同步通信流量的丢包甚至会导致系统崩溃[2]. 在现代数据中心中，数据包丢失导致的超时等待时间会极大延长时延敏感业务的完成时间[3-4]. 此外，随着算力效率的提升和大模型等新型算力应用的兴起，新型算力应用对网络时延、吞吐量等有了更高要求. 研究表明，在大模型场景中，1‰的网络丢包率将使模型有效计算时间占比下降13%，极大影响模型训练效率[5]. 与此同时，远程访问内存（remote direct memory access，RDMA）技术由于其硬件卸载带来的服务器端时延和吞吐量的性能优势，逐渐成为各类新型算力应用的关键技术之一. 然而，RDMA技术需要底层网络无数据包丢失才能发挥其最大性能优势[6].
因此，无丢失网络逐渐成为重要的网络基础设施. 无丢失网络是指在正常情况下数据包不会因网络中交换机缓存溢出而被丢弃的网络. 目前2类主流的无丢失网络是无丢失以太网和无限带宽网InfiniBand. InfiniBand发展于高性能计算领域，用于高性能计算机之间或者存储系统之间互联，支撑大规模专用计算任务的数据通信. InfiniBand原生支持RDMA技术、基于虚拟通道的网络服务质量保证和以子网为单位的隔离功能. 无丢失以太网起源于基于以太网的数据中心，以面向用户服务为主，承载在线密集型、分布式存储、分布式计算等多种类型的应用. 随着数据中心应用对端到端时延、吞吐量等提出了更高的要求，RDMA技术被引入到以传统TCP/IP协议为主的数据中心服务器，并在近年来发展出了基于融合以太网的RDMA传输协议RoCE（RDMA over converged Ethernet）.
无丢失以太网和InfiniBand均使用链路层的流量控制机制来保证网络的无丢失特性，但其也附带了一些负面问题（如队头阻塞、死锁等），这影响了无丢失网络在带宽、时延、可靠性等方面的性能，因此，如何有效降低链路层流量控制的负面影响成为无丢失网络实现高效传输的关键挑战. 近年来，学术界和工业界设计提出了大量的流量管理方案，通过合理的网络资源分配来缓解或消除链路层流量控制的负面影响，保证数据包无丢失的同时提升应用的整体传输性能，从而推动无丢失网络的规模化部署. 本文将综述这2类无丢失网络在流量管理方面的最新进展.
本文对无丢失网络流量管理研究进行综述，主要贡献有3个方面：
1）以无丢失以太网和InfiniBand这2种典型的无丢失网络为例，介绍各自发展背景和应用特征，并从保障无丢失特性的链路层流量控制机制出发总结了无丢失网络流量管理的目标，归纳了无丢失以太网和InfiniBand流量管理的传统架构.
2）根据对流量管理驱动的位置或者技术手段，分别对InfiniBand和无丢失以太网的流量管理的最新研究进展进行分类，包括发送端驱动的拥塞控制、接收端驱动的拥塞控制、拥塞隔离、多路径负载均衡等，并分析总结对应的优势以及局限性.
3）对无丢失网络的流量管理研究进行了展望，指出了研究人员未来需要着重对无丢失网络流量管理统一架构、面向领域应用的流量管理以及机内与网络联合流量管理3个方向进行深入探索，才能使得无丢失网络具有更好的可扩展性和适用性.
1. 背景介绍
1.1 无丢失网络分类
1） InfiniBand
在高性能计算中，InfiniBand受到广泛应用. 据报道，在全球TOP 500榜单上的超算系统中，InfiniBand占主导地位[7]；高校、研究机构和政府机构的高性能计算集群中有70%部署了InfiniBand[8].
为了避免因通信流量丢失而降低系统可靠性和损害延时性能，InfiniBand行业协会（InfiniBand Trade Association，IBTA）在InfiniBand 标准中就提出底层网络支持无丢失的特性，采用基于信用的链路层流量控制（credit based flow control，CBFC）[9]. CBFC工作在交换机端口的虚拟通道（virtual lane，VL）级别. VL是共享一条物理链接的相互分立的逻辑通信链路，每条物理链接可支持多达15条的标准VL和一条管理VL. 如图1（a）所示，在CBFC中，下游交换机为每个VL维护一个调整块寄存器（adjust block register，ABR）来记录接收到的块总数. 此外，下游交换机周期性地向上游交换机发送流量控制信用限制（flow control credit limit，FCCL）消息，消息内容是分配的缓冲区大小和 ABR 大小之和. 上游交换机为每个VL维护一个流量控制总发送块（flow control total block sent，FCTBS）寄存器来记录已发送的块总数. 收到FCCL消息后，可用信用的数量即是FCCL和FCTBS数量之间数量的差值，上游交换机只有在有可用信用时才能发送数据包，每发送一个数据包，FCTBS寄存器增加相应值，相当于可用信用数量减少相应值.
InfiniBand与数据中心中的以太网具有不同的物理层和链路层. 早期InfiniBand的链路速度发展快于以太网. InfiniBand交换机采用直通式转发以降低转发时延. 端主机侧原生支持旁路内核的远程访问内存RDMA技术，大幅度提升了端主机的性能. 作为专用的网络技术，InfiniBand需要特殊的网卡通道适配器（channel adapter，CA）和交换机，支持以子网（subnet）为单位管理控制，具有更高的建设成本和运营管理的复杂性.
InfiniBand自诞生起便支撑高性能计算应用. 这类应用面向复杂的大规模科学与工程计算、数值模拟和数据分析等问题，使用多个高性能计算机运行并行计算模型. 由于并行计算模型通常按照一定规则进行分割以实现并行数据或者并行任务，因此从网络的角度看，高性能计算应用的流量具有一定的模式和规律性. 具体而言，高性能计算机广泛使用消息传递接口（message passing interface，MPI）进行进程间通信，MPI支持AllReduce，AlltoAll，Broadcast等多种集合通信原语，这类集合通信涉及多个发送方和接收方以实现结点间高效数据通信，例如AllReudce通信原语将不同机器中的数据整合（reduce）之后再把结果分发给各个机器，Broadcast通信原语将本地的数据分发给其他各个机器等.
2） 无丢失以太网
以太网凭借成本低、操作简单和兼容性广的优点，一直是局域网的首选网络技术. 然而，以太网这种保持简单、低成本的理念也导致需要为一些具有更严格要求的应用单独设计专用网络. 例如在多种业务需求下，通信基础设施就需要包括多个不相交的网络，如使用以太网技术的局域网、使用Fibre Channel技术的存储区域网和使用InfiniBand的高性能计算网络等. 维护这些专用网络带来了较高的成本，同时增加了维护和管理的复杂性.
但是，现代数据中心已普遍采用了在传统互联网中占主导地位的以太网. 鉴于此，IEEE 数据中心桥接（data center bridging，DCB）工作组致力于增强以太网的能力使之成为一个统一的交换结构，从而取代传统的为特殊需求设计的各个独立的专用网络，包括存储区域网、高性能计算网络和数据中心局域网等. 与维护多个独立的专用网络相比，聚合增强型以太网（converged enhanced Ethernet，CEE）具有显著的性能、成本和管理优势. CEE在链路层开发了逐跳的优先级流量控制（priority flow control，PFC）[10]来支持多种应用场景需要的无丢失特性. 因此，CEE也被称作无丢失以太网. 在无丢失以太网中，PFC工作在交换机端口的队列级别，如图1（b）所示，交换机入端口队列设置阈值Xon和Xoff，当队长超过Xoff时，向上游发送暂停帧PAUSE，通知上游端口停止发送数据，在队列长度降至Xon之后发送恢复帧RESUME，通知上游端口恢复数据包的发送，最终确保了交换机不会因缓存溢出而丢弃数据包.
另一方面，RDMA在数据中心的应用也促进了无丢失以太网的发展. 使用RDMA技术，数据传输不需要内核的参与，传输协议栈卸载到网卡上，数据直接从一个主机系统的存储区快速传输到另外一台远程主机的存储区. 与基于软件的TCP/IP网络协议栈相比，RDMA硬件卸载和旁路内核的特性显著降低了CPU开销和整体时延. 例如，使用RDMA后，数据中心分布式机器学习的训练加快了100多倍[11]. 但根据经验，RDMA的数据传输只有在没有数据包丢失时才能达到其最佳性能[6]. 因此，近年来基于融合以太网的RDMA传输协议RoCE以及扩展的支持3层IP网络的RoCEv2[12]得到了很大关注.
无丢失以太网近年来开始支撑数据中心的多种业务. 然而数据中心业务的通信模式具有几个显著的特征，对无丢失以太网的传输性能提出了更高的要求. 首先，数据中心业务往往具有高同步与高突发的特征. 以典型在线搜索应用的分割聚合模式为例，当底层大量机器被同时分配任务后，可能会在很相近的时间内同步完成并返回结果，造成高同步的并发流量通信模式 Incast[13]. 高同步的并发流可以在一个RTT内占满汇聚层机器的下行带宽，造成相应交换机网口缓存耗尽和PFC触发，进而导致网络中更多的交换机产生队列累积，使得网络通信的尾部时延增加. 与此同时，数据中心流大小通常表现出长尾分布[14]. 比如，在网页搜索业务负载[15]中，50%的流是小于100 KB的小流，而80%的数据量来自占比10%的大于10 MB的流. 随着数据中心链路带宽的增加，时延带宽积（bandwidth delay product，BDP）不断增大，网络中将存在很多在1个RTT内即可完成的突发性的小流，而端到端的拥塞控制很难及时控制小流，当很多小流并发到达时，极易造成短时间内交换机缓存耗尽和PFC的触发.
除此之外，iWARP[16]是一种基于TCP/IP协议栈的远程直接内存访问技术，设计用于在广域网和局域网环境中提供高效、低延迟的数据传输. 与InfiniBand和RoCE相比，iWARP直接构建于标准的以太网和TCP/IP协议之上，可以集成到现有的IP网络基础设施中，无需对网络架构进行大幅度改动. 由于iWARP基于TCP/IP协议栈，因此相比InfiniBand或RoCE可能引入更多的协议开销. 目前，iWARP在一些特定领域中（需要与现有网络基础设施兼容或需要长距离、跨广域网连接等）具有较大应用前景.
1.2 无丢失网络流量管理的重要性
与传统有丢失网络不同，无丢失网络流量管理的目标有其特殊性，其来源于无丢失网络特有的链路层流量控制机制.
无丢失以太网和InfiniBand均使用链路层的流量控制机制来保证网络的无丢失特性，可以很好地避免瞬时拥塞导致的交换机丢包. 但是，链路层流量控制工作在交换机端口的队列或VL级别，一方面对于流是无感知的，另一方面队列数目和VL数目受到的交换机硬件限制是有限的，链路层流量控制如果被持续触发，可能带来一些附带损害.
1）队头阻塞问题. 如图2（a）所示，当多条流量同时去往相同的目的地导致拥塞时，随着队列长度的增加，链路层流量控制向上游交换机触发，并逐渐向源端传播，网络中形成一棵拥塞树. 在拥塞流经过的路径上，流量即使不去往拥塞点也会被阻塞在队列中，带来了队头阻塞问题. 队头阻塞导致网络链路没有被充分利用，损害了无辜流量（也称受害者流）的性能. 队头阻塞问题往往与拥塞扩展同时出现，即拥塞点处的拥塞扩展到了网络中其他链路. 例如，在InfiniBand集群的测量研究表明，架顶交换机的上行链路端口在以100 ms为单位的观察间隔内，有约60% 时间处于等待信用的状态[17].
2）公平性问题. 如图2（b）所示，4条流去往同一目的地，理想情况下4条流应当均分瓶颈链路带宽，即各分得 C/4（假设链路带宽为C）. 但是，由于链路层流量控制不能区分流，在交换机拥塞点处只能按照不同入端口分配带宽，最终导致共享同一端口队列或VL的2条流F1和F3得到了偏低的带宽分配，F4和F7得到偏高的带宽分配.
3）死锁风险. 在实际部署中，开启链路层流量控制可能使得网络有死锁的风险. 网络中可能由于路由配置错误、交换机固件故障或链路故障等多种原因导致网络中出现循环缓冲区依赖（cyclic buffer dependency，CBD），一旦链路层流量控制触发时，如图2（c）所示，由于CBD的存在，在环路中的所有交换机都暂停了上游交换机端口队列或VL的发送，并同时等待下游端口恢复数据包传输的信令，网络会进入停滞状态，极大降低传输性能[18-20].
1.3 无丢失网络流量管理传统架构
上述无丢失网络中链路层流量控制带来的负面影响，其背后的根本原因是网络输入流量过量导致拥塞的发生，而仅通过链路层流量控制，无法实现合理的每流带宽分配. 因此，有效的流量管理是必要的. 无丢失网络的流量管理的首要目标是对网络中流量进行合理控制，消除网络中的拥塞，避免链路层流量控制的持续触发，缓解一系列负面影响，是使能大规模无丢失网络的关键技术.
无丢失以太网和InfiniBand早期的相关标准中均制定了相似的流量管理架构，以被动式流级别的拥塞控制为主要的技术路线，主要包括拥塞探测、拥塞通知和拥塞控制3部分. 拥塞探测可以探测到网络中拥塞的出现，用于检测网络中的拥塞情况，同时进行拥塞识别以确定导致拥塞的拥塞流. 如果是网络内交换机负责实施拥塞探测与识别，还需要拥塞通知将拥塞相关的信息通知给源端主机. 最终，源端主机依靠端到端的拥塞控制对拥塞流进行相应的速率调整，尽快解决网络中的拥塞. 其中，拥塞探测是流量管理架构的基石，它是流量管理中首先需要解决的问题，它的探测结果决定了端到端拥塞控制的响应对象. 速率调节是端到端拥塞控制的核心，它的调速结果决定了最终每流的带宽分配.
2. InfiniBand流量管理研究进展
InfiniBand建设成本高昂，由于主要面向单一的高性能计算应用，对于个性化的应用需求以及不同的物理集群通常可以定制不同的解决方案. 近年来，InfiniBand流量管理发展出了多种技术路线，除了传统流级别的拥塞控制外，还有拥塞隔离、自适应路由以及端点主动拥塞控制等.
2.1 拥塞控制
1） 发送端驱动的拥塞控制
IBTA制定的InfiniBand规范中的附录部分指定了InfiniBand网络中的拥塞控制框架和拥塞控制机制IBCC[9]. 如图3所示，交换机负责探测拥塞，接收端主机负责将拥塞通知给发送端，CA执行对注入流量的速率调节. 其中交换机依赖队长信息和信用值的有无来判断拥塞并识别拥塞流. 发送端的速率调节依赖预设的速率调节表CCT. 发送端维护一个指针索引用于指向当前速率的表项，通过定时器辅助的指针移动来改变当前速率，从而实现增速或减速.
挪威模拟研究实验室和迈络思的研究人员最早使用迈络思ConnectX系列网卡和InfiniScale IV交换机对IBCC进行相关实验，结果表明IBCC经过合适的参数配置后可以有效缓解队头阻塞问题，实现对典型高性能计算基准测试的吞吐量性能提升[21]. 但是，IBCC 维护速率调节表的方式一方面不能适应动态网络状况，另一方面往往需要针对集群和工作负载特点进行大量参数调优才能获得理想的收敛性能. 因此，尽管商用交换机已经支持了IBCC，但是其复杂的参数调优造成了其在实际中部署困难，一些高性能计算集群甚至不开启IBCC[17,22].
意识到IBCC参数调优的复杂性问题，一些工作提出更快收敛、更易调优的IB拥塞控制算法. 核心思想在于对拥塞控制算法的减速部分提供更加明确的指导信息，以减少逐步的启发式调节. 例如，Liu等人[23]提出利用链路利用率信息对IBCC进行增强；最新的由Zhang等人[24]提出的RRCC，采用接收端观察到的接收速率指导发送端的速率调节，实现接收端驱动的速率调节和拥塞识别，能够达到比IBCC更佳的收敛性能和对突发流量的容忍性.
2） 端点主动拥塞控制
针对高性能计算进程通信中存在的多对1流量模式易导致端点拥塞的问题，同时为了克服被动式拥塞控制的根本性不足，一些工作提出采用主动拥塞控制的思想来避免端点拥塞.
英伟达的研究人员在SC会议上提出SRP[25]，该方案使用轻量级的预留握手协议提前避免拥塞. 发送端首先向接收端发送一个高优先级的预留数据包，指示其打算传输的数据量. 当接收端接收到该预留分组时，向发送端返回一个授权分组，指示可以发送的传输时间. 发送端在发出预留分组后直接发送投机数据包，而不必等待授权分组到达. 投机数据包在低优先级VL上传输，如果网络端点无拥塞，则投机数据包将完好无损地到达目的地. 然而，当网络端点出现拥塞时，投机数据包在网络中遇到较大的排队延迟，短暂超时后网络将丢弃投机数据包，并向发送端返回否定确认（negative acknowledgment，NACK）. 当发送端收到投机数据包的确认或NACK时则停止投机性传输. 当发送端达到指定的传输时间时，再以非投机模式传输消息的其余部分，并重新传输任何先前丢弃的数据包. 以非投机模式发送的数据包使用比投机数据包更高优先级的单独VL，从而保证了投机数据包经历的任何排队延迟不会影响非投机数据包.
SRP采用的预留协议会带来握手开销，当网络中短消息占主导时，握手开销对于消息性能可能是难以接受的. 因此，后续的研究工作SMSRP[26]提出不需要为每个消息进行提前预留操作，当消息准备好时，发送端立即以投机模式传输，消息使用低优先级VL，并且在发生拥塞时可以被网络丢弃. 如果投机传输成功，也即当端点无拥塞时，SMSRP几乎不会在网络中产生任何开销. 如果网络端点发生了拥塞，投机数据包可能被网络丢弃，网络交换机直接将相应的 NACK发送回源发送端. 当源发送端收到NACK时，会向目的地发起预留请求以获取消息的重传时间. SRP等机制由于只能解决最后一跳端点处发生的拥塞，因此提出与其他机制（如自适应路由等）配合使用来缓解网络内的拥塞.
2.2 拥塞隔离
针对链路层流量控制无法区分不同流而导致队头阻塞、不公平等问题的局限，InfiniBand中一些研究工作提出了拥塞隔离的思想来从根本上解决链路层流量控制的附带损害. 在InfiniBand交换机中，基于信用的流量控制机制以VL为单位工作，属于不同 VL 的流量互不干扰. 与传统以太网交换机通常仅支持每端口最多8个队列不同，在InfiniBand交换机中，每个端口有16个VL. 因此，可以使用不同VL来隔离拥塞流以避免阻塞其他流. 这类研究工作主要分为静态拥塞隔离和动态拥塞隔离.
1） 静态拥塞隔离
静态拥塞隔离指根据提前获知的流量模式和网络拓扑结构定义流量类别到VL的映射. 挪威模拟研究实验室的研究人员提出了vFtree[27]，根据Fattree网络拓扑路由时只需要决定流量上行链路的特点，提出将共享相同上游链路的流按照〈源发送端，目的接收端〉进行分组，并均匀分布在不同的VL上. 但是，随着网络规模越来越大，并且交换机支持的VL的数量有限（例如，每端口最多有16个VL，通常8个VL可用于数据流量[28]），并非所有的流量都可以隔离在不同的VL中，仍然会有不同流量共享同一VL. 尽管后续有研究人员提出了可以灵活调整VL映射的方案[29]，但总体而言静态拥塞隔离只能缓解部分的队头阻塞等问题.
2） 动态拥塞隔离
动态拥塞隔离的主要思路是交换机根据动态的拥塞状况进行流量隔离，实现避免队头阻塞的同时高效利用交换机资源.
西班牙瓦伦西亚理工大学等的研究人员提出的RECN[30-31]是动态拥塞隔离的代表性工作. RECN的核心思想是快速检测拥塞流并立即将其映射到单独的交换机队列. 通过允许到达交换机输入端口的非拥塞流的所有数据包共享同一队列，从而显著减少消除队头阻塞所需的队列数量. 拥塞流的所有数据包都将存储在单独的队列中，因此它们之间不会相互干扰，也不会干扰非拥塞流. 具体而言，当某个输入端口收到拥塞通知时，会在本地为去往拥塞输出端口的数据包分配预留队列（set aside queue，SAQ）. 所有请求拥塞的输出端口的数据包都将存储在该SAQ中. 如果拥塞持续存在，该SAQ的队长将持续增加. 当SAQ占用率达到阈值时，拥塞通知将传播到上游交换机. 上游交换机将维护状态信息，记录本端口为拥塞树叶子结点等. 随后，新的SAQ将被分配到该输出端口. 同样，当SAQ占用率达到阈值时，它会向将数据包转发到该输出端口的同一交换机上的所有输入端口通知拥塞，并用标志记录此类操作. 如果拥塞持续存在，则重复该过程，将拥塞通知和SAQ分配传播到受拥塞树影响的上游交换机，最终可能扩展到拥塞流的源发送端. SAQ资源的释放与上述过程类似，当SAQ占用率为空或低于阈值时，释放该队列并通知下游结点，最终到达拥塞树的根结点.
交换机动态隔离方案能够近似模拟每条流使用单独的队列，很大程度上避免队头阻塞等问题，并且具有良好的可扩展性，能够支持较大规模的网络. 但是，其需要较多的交换机资源实现一系列复杂的机制，尚未有硬件可部署的交换机解决方案.
2.3 多路径负载均衡
InfiniBand 网络中，去往同一目的结点往往有多条等价路径. 当网络内拥塞发生时，将发生拥塞的链路上的流量分散到其他链路利用率较低的等价路径上，可以暂时缓解网络内的拥塞. 因此一些研究工作提出使用先进的多路径负载均衡技术来缓解拥塞.
1）静态路由
静态路由通过预先计算的算法确定性地决定每一跳，保证网络内尽可能少地发生拥塞. 例如，西班牙瓦伦西亚理工大学的研究人员提出用于Fattree网络拓扑的确定性路由算法[32]，按照目的地址的顺序将其分配到不同的上行链路中，使得去往不同目的地址的流量会被路由到下一阶段的不同交换机. 这种针对连续目的地址的路由算法对于目的地址均匀分布的工作负载较友好，同时也不会引入数据包乱序问题. 实际上，静态路由算法通常只适用于特定的拓扑和流量模式，通常需要针对工作负载定制设计.
2）动态路由
动态路由根据网络拥塞情况确定每包走的路径. 主要分为基于源端的方案、基于交换机方案和基于集中控制器的方案.
早期美国Myrinet高性能计算集群使用了基于源端的分散路由方案[33]. 首先，当源端网卡因受到链路层流控影响而停止发送时，或者当被阻塞的数据包超过一个阈值后，认为网络中有拥塞发生，为数据包以一定概率随机选择其他的路径. 其次，为了避免重新选择的路径仍存在拥塞，在选择路径前，先发送微秒级探测包探测可选路径是否是拥塞的，重复此过程，直到最终找到可用路径或多次探测所有路由. 由于Myrinet中网络协议在设计时就对数据包乱序具有良好容忍性，因此分散路由引入的数据包乱序不会带来性能影响. 但是这种基于源端的分散路由方案通常只有端点视角的局部信息，无法保证快速将数据包分配到负载低的路径.
迈络思提出交换机直接根据端口负载状况选择等价路径，即交换机自适应路由（adaptive routing，AR）[34]. 交换机为流量动态选择拥塞程度最低的端口进行传输，并且支持调整路由的粒度. 拥塞程度基于出口队列负载状况（队长、链路利用率等）进行评估，可能需要针对不同拓扑和负载进行参数调整. 自适应路由使得相同流的不同数据包可能经过网络的不同路径，因此会出现数据包乱序问题. 由于RDMA传输协议默认数据按序到达，乱序数据包会被视作丢包从而重传，降低了RDMA传输的吞吐量. 因此，交换机自适应路由方案还需要端侧RDMA网卡的配合. 目前，一些商用网卡开始支持数据包的乱序交付，如英伟达的ConnectX-7[35]，BuleField-3 DPU[36]等.
为了更好地适应工作负载的动态流量需求，美国劳伦斯利弗莫尔国家实验室等的研究人员提出了流感知的自适应路由AFAR[37]. 控制器根据运行时更新的工作负载流量矩阵以及路由表，重复查找网络中最拥挤的链路，根据通过该链路接收数据的目标结点信息，为发送到该目标结点的所有数据重新选择路径以缓解网络内的拥塞. AFAR需要对MPI库以及InfiniBand系统软件进行修改以实时获取任务负载信息和及时更新路由.
总体而言，动态路由的局限在于其不能解决拥塞的根源，即不能控制发送过量的发送端，只能短暂地缓解网络内部的拥塞，对于典型Incast流量模式导致网络最后一跳处的拥塞（也称端点拥塞）也无能为力.
2.4 其 他
除了上述4类流量管理方案，西班牙卡斯蒂利亚-拉曼查大学的研究人员指出发送端驱动的拥塞控制扩展性好，但反应时间长、收敛慢，而拥塞隔离能够迅速隔离拥塞流，但由于交换机支持队列数量有限，可扩展性差，因此提出了CCFIT[38]，结合这2类方案的优势，相互补充，有效解决队头阻塞等问题. 一方面，动态拥塞流隔离可以在端侧尚未感知到拥塞的出现时消除部分队头阻塞；另一方面，对拥塞流的速率调节也会进一步降低在端口中同时存在许多拥塞流的可能性，减少所需物理队列数量. 实验表明CCFIT实现比IBCC更好的吞吐量性能，同时比动态拥塞隔离消耗更少的交换机资源.
2.5 InfiniBand流量管理小结
InfiniBand中被动拥塞控制以IBCC为代表，能够解决端点拥塞和网络拥塞，交换机设计简单、可扩展性高，但是其性能易受参数影响. 对于拥塞隔离机制，一方面其性能受限于目前交换机可用VL的数目，另一方面理想的动态解决方案需要复杂的交换机硬件设计，难以适用于大规模负载和网络. 自适应路由和端点主动拥塞控制机制不能同时适用于处理网络内和端点的拥塞，但可以作为缓解拥塞的辅助手段. 现有做法通常根据高性能计算负载的特点（例如流量模式是否均匀、有无端点拥塞等），选择合适的流量管理手段. 表1总结对比了已有InfiniBand流量管理方案.
表 1 InfiniBand主要流量管理特点对比Table 1. Features Comparison of Main Traffic Management in InfiniBand流量管理
方案代表
算法处理端点
拥塞处理网内
拥塞可部署性 被动拥塞
控制IBCC[9] 是 是 商用网卡已支持，
需参数调优RRCC[24] 是 是 需修改网卡 拥塞隔离 RECN[30] 否 是 交换机设计实现复杂，
尚无商用交换机支持多路径负
载均衡vFtree[27] 是 是 无数据包乱序，但仅适用
于特定拓扑和负载AR[34] 否 是 有数据包乱序，部分商用
交换机和网卡已支持AFAR[37] 否 是 无数据包乱序，需要修改
MPI库和子网控制器端点主动
拥塞控制SRP[25] 是 否 接收端网卡设计复杂 SMSRP[26] 是 否 接收端网卡设计复杂 其他 CCFIT[38] 是 是 交换机设计实现复杂，
尚无商用交换机支持3. 无丢失以太网流量管理研究进展
无丢失以太网流量管理的主要技术手段是流级别的拥塞控制，以微软亚洲研究院2015年提出的DCQCN[39]为标志性工作，通过调节每流的发送速率解决网络中的拥塞，同时避免PFC的持续触发，提高应用的时延和吞吐量性能. 此外，受到基于TCP的传统数据中心网络影响，无丢失以太网近年来也开始利用多路径负载均衡进一步缓解网内热点. 在本节中，我们主要介绍拥塞探测、拥塞控制、多路径负载均衡方面的研究进展.
3.1 拥塞探测
根据拥塞探测执行的位置或者实体，现有研究进展可以分为基于交换机的拥塞探测、基于端主机的拥塞探测以及交换机和端主机协作的拥塞探测.
1）基于交换机的拥塞探测
在无丢失以太网中，IEEE DCB工作组在IEEE 802.1 Qau中规定了量化拥塞通知（quantized congestion notification，QCN）[40]. 在QCN中，拥塞点（congestion point，CP）采样队列大小来计算拥塞的度量Fb. 假设采样时刻瞬时队列为Q，期望队列长度为Qeq，则度量值Fb根据上次采样时刻的队长增量Qδ = Q – Qold，以及采样时刻瞬时队列和期望队列的差值Qoff = Q − Qeq的线性组合计算.
但是，由于现代数据中心交换机普遍支持的是基于队列长度探测拥塞并使用ECN标记，无丢失以太网中广泛采用的拥塞探测机制是基于队列长度的拥塞探测. CP根据RED算法[41]标记ECN. RED算法包含Kmax，Kmin，P 三个关键参数.当队长超过Kmax时，交换机以概率1标记数据包；当队长处于Kmax与Kmin之间时，以概率P标记数据包；最后，当队长低于Kmin时，不对数据包标记. 单个比特的ECN标记表示该流经历拥塞，即为拥塞流.
上述思想均为基于交换机队长进行拥塞状况的判断. 然而，Zhang等人[42]指出，仅基于队长的拥塞探测在无丢失以太网中容易造成错误的探测结果. 当端口因下游链路层流量控制触发而关闭时，也有可能有队列累积，而并非发生了拥塞. 此时根据队长标记ECN可能导致误伤受害者流. 因此，对无丢失网络交换机端口状态空间进行了重新划分. 定义第1种状态为拥塞态，端口持续发送，队长有累积. 第2种状态为待定态，端口发送模式为间歇性ON-OFF，队长可能有累积. 第3种状态是不拥塞态，端口持续发送，无队长累积.
基于上述3种状态，文献[42]提出了交换机三元拥塞探测（ternary congestion detection，TCD）机制，考虑端口因流量控制触发的ON-OFF状态特征进行状态探测，能够准确区分出拥塞发生的端口、受到链路层流量控制触发影响的端口以及不拥塞的端口，重用了ECN的2 b标记位传递三元状态信息. 其中，处于待定态的端口的真实流量输入速率可能由于上游链路层流量控制的调制作用而被掩盖. 图4展示了三元状态的转换条件，其中的关键是区分出持续ON和ON-OFF的发送模式. TCD给出了ON周期上界的计算方式，交换机可以提前配置ON周期的上界来区分2种发送模式. TCD是为无丢失网络量身定制的拥塞探测机制，但需要对网络交换机进行改动.
2）基于端主机的拥塞探测
隐式的丢包信号不再适用于无丢失网络. 因此，谷歌公司提出将基于RTT梯度的拥塞探测应用于无丢失以太网[43]. 基于RTT梯度的拥塞探测算法计算连续周期的RTT之间的差值，使用EWMA平滑来估计拥塞程度. 此外，文献[44]提出了类似的思想，在高性能计算系统中使用分布式应用运行时间的梯度进行网络拥塞探测.
使用RTT或RTT梯度等端到端的延时信号，无需网内设备支持，具有灵活、可部署性高的优点. 但是，由于无丢失网络中存在特有的链路层流量控制，拥塞发生后，一旦链路层流量控制向上游生效，上游端口发生队头阻塞后，即使是拥塞无关的流量也可能经历排队，端主机会观察到延时的增加. 因此，仅基于端到端的延时信息和端到端的拥塞探测方式可能难以区分因拥塞引起的延时增加和因逐跳流量控制生效引起的延时增加.
3）交换机和端主机协作的拥塞探测
最近无丢失以太网中的一些研究工作提出采用交换机和端主机协作的方式探测拥塞和识别拥塞流. Cheng等人[45]提出的PCN中给出了NonPAUSE ECN（NP-ECN）的拥塞探测识别方法. 交换机维护一个计数器来记录被暂停数据包的数量. 只有未被暂停的数据包才允许使用ECN进行标记. 在接收端网卡处，当被标记ECN的数据包的比例在一段时间内超过1个阈值（如95%）时，识别该流为拥塞流. NP-ECN本质是一种启发式的方法，认为拥塞流不会经历交换机端口暂停，基于此将拥塞流筛选出来. NP-ECN部分缓解了无丢失以太网中由于PAUSE帧导致的队长增加混淆拥塞探测的问题，但是其周期性参数设置在不同网络拓扑下可能不适用.
Li等人[11]提出的HPCC通过已发送但还未确认的数据包数量判断拥塞程度. 这种方式需要依靠全网部署带内网络遥测（in-band network telemetry，INT）[46]技术. 数据包传输时，每经过一个交换机，添加相应元信息字段来携带该交换机处传输的字节数和队列长度信息. 发送端根据路径上所有交换机的信息来最终计算最拥塞链路上正在传输但还未被确认的字节数. 总之，NPECN和INT都不是交换机上独立的拥塞探测机制，需要与端主机的拥塞控制算法协同配合才能探测拥塞以及识别拥塞流.
3.2 拥塞控制
根据拥塞控制驱动调速决策的位置或实体，现有研究进展可以分为发送端驱动的拥塞控制、交换机驱动的拥塞控制和接收端驱动的拥塞控制.
1） 发送端驱动的拥塞控制
发送端驱动的拥塞控制的思想是先探测拥塞的出现，发送端获取拥塞信号后做出速率调节. IEEE DCB工作组提出的QCN[40]属于此类. 在其拥塞控制框架中，使能QCN功能的网络交换设备CP负责拥塞探测，探测到拥塞后，交换机同时作为通知点（notification point，NP）产生显式拥塞通知信号直接发送给发送端，最后发送端主机负责速率调节的反应点（reaction point，RP）. 发送端采用乘性减速和类似BICTCP[47]的自增型二分速率增长算法. 其中分别使用了字节计数器和定时器根据发送数据量和发送时间自增加发送速率.
但是，QCN基于2层网络设计，不能在实际的3层 IP 网络中部署. 因此，沿着QCN的思路，Zhu等人[39]在2015年基于商用交换机普遍支持的ECN功能提出了DCQCN. 在DCQCN中，接收端作为通知点，将拥塞通知信号返回给发送端. 发送端如果在1个控制周期内收到拥塞通知信号，则降低流的发送速率，否则使用定时器和字节计数器决定流的增加速率，速率增长规则与QCN类似. 受当时硬件条件限制，控制周期采用55 μs，DCQCN根据1个控制周期内收到的拥塞信号，采用启发式的逐步调节，通过维护ECN比例的指数加权滑动平均值α. 每当收到拥塞信号则乘性降α/2，因此可能需要多个RTT才能收敛到理想速率. 目前商用RoCEv2网卡普遍支持DCQCN，是工业界广泛使用的无丢失以太网的拥塞控制算法.
莱斯大学和IBM的研究人员在2014年联合提出的TCP Bolt[48]，是早期为无丢失以太网设计的流级别的拥塞控制，其算法本质上是去掉了慢启动阶段的DCTCP[15]. 但是基于拥塞窗口的TCP Bolt 尚未在硬件网卡上得到支持，而在终端主机协议栈上的实现会带来较大的CPU开销和延时.
几乎与DCQCN同时，Mittal等人[43]借鉴广域网中拥塞控制算法的思想，为无丢失以太网提出了基于RTT梯度的TIMELY算法. TIMELY指出现代网卡已经支持利用ACK对端到端时延进行微秒级测量，因此RTT中蕴含了丰富的多比特拥塞信息，可以在一定RTT范围内根据梯度启发式降低发送速率. 当RTT小于阈值Tlow时，认为网络无拥塞、队列空载，可以增加发送速率；当RTT大于阈值Thigh时，认为网络拥塞导致的排队严重，应当减小发送速率；当RTT介于二者之间时，将梯度乘以一个减速系数调整发送速率. 但是，这种基于梯度的方法有研究分析指出其在高度动态网络下的收敛性能不佳[49]. 2020年，Kumar等人[50]对TIMELY算法进行改进提出了Swift，Swift使用时延的绝对值而不是梯度进行速率调节，通过细粒度时延测量，解耦网络时延和主机时延，并使用了2个窗口分别处理主机内拥塞和网络拥塞. 窗口演变均使用AIMD原则，相比TIMELY，Swift能够更高效地处理大规模Incast，具有更好的时延性能和鲁棒性.
除了沿用传统有丢失网络的思路，2019年Liu等人[11]提出了基于精确链路负载信息的高精度拥塞控制方案HPCC. HPCC的重要见解是认为已有方案慢收敛、长队列、调参复杂等问题的根本原因是传统网络缺乏细粒度的网络负载信息. 因此，提出根据精确的链路负载信息感知每流状态进行细粒度调速. 对链路上正在传输但还未确认的字节数Ij进行控制，采用基于窗口调整的方式，使每条流路径上每个链路的Ij略低于链路带宽Bj×T（例如95%）. 对于链路j，每个发送方采用乘性增、乘性减（MIMD）和加性增（AI）结合的思想调整发送窗口. HPCC需要全网部署INT技术，带来了较高的每包携带开销，可部署性较低. HPCC追求非常低的交换机队列长度以获得较好的延时性能，但牺牲了长流的吞吐量. 此外，每包携带INT信息也进一步损害了吞吐量性能.
与已有沿用传统有丢失网络方法或者利用先进测量技术不同，Zhang等人[51]提出的拥塞控制算法ACC则独辟蹊径，提出充分利用无丢失以太网自身的特性来指导发送速率的控制. 受TCD挖掘PFC对状态探测影响的启发，ACC指出链路层流量控制PFC不仅影响了交换机端口状态，而且还在保证中间交换机结点不丢包的同时，保证了端到端整条路径的无丢失. 因此，无丢失以太网具有一个重要的属性：数据包守恒，即发送入网络中的数据包数量总等于网络中排出的数据包数量. 基于该特性，ACC提出了2个重要的拥塞控制指导原则：首先，应当使用ACK驱动的方法来推断拥塞流的网络管道容量以及精确过量的数据包数目；其次，为根本缓解无丢失以太网的队头阻塞问题，应当对拥塞流进行充分抑制来尽快清除交换机中累积的数据包，受害者流则应当根据拥塞扩展程度动态调整速率. ACC需要与TCD配合使用，识别出流状态后，对拥塞流实行一种2步的调速策略：首先拥塞流进入源停止（source halt）状态等待过量的数据包排出，然后将发送速率与由ACK到达速率推断出的管道容量进行匹配. 对于受害者流，则根据TCD标记中待定态（undetermined experienced，UE）的持续时间超过一定时间阈值后，才进行减速调整. ACC引入的源停止状态以最快的速度抑制了队头阻塞及其负面影响，同时能够实现较好的延时和吞吐量性能.
2） 交换机驱动的拥塞控制
Taheri等人[52]提出的RoCC是交换机驱动的拥塞控制机制. 由交换机负责做出调速决策，发送端只负责执行限速. RoCC利用了交换机的可编程能力，使用一个PI控制器计算出每流的公平速率通知给源端，源端直接按照公平速率发送. 其中公平速率R的计算主要基于3个变量：当前队长（Qcur）、队长变化方向（Qcur − Qold）和参考队长偏差（Qref），即
R ← R − α × (Qcur − Qref) − β × (Qcur − Qold).
RoCC交换机维护当前流的数目N，并根据N的大小自动调整PI控制器的参数α和β. 对于较大的公平率值（较小的N），α和β应较大，以确保快速收敛而不失去稳定性. 相反，对于较小的公平率值（较大的N），α和β应该很小. 实验表明RoCC能够维持稳定的队列长度，但是与传统数据中心一些基于交换机的调速方案类似，仍存在计算复杂性较高等局限.
3） 接收端驱动的拥塞控制
为克服启发式调速的不足，接收端驱动的拥塞控制通常由接收端显式指导发送端的速率调节，避免了被动式的反应，通常具有更好的收敛性能.
接收端驱动的拥塞控制最早由传统数据中心有丢失的以太网提出，并不是专为无丢失以太网设计的，但是通常被认为可以实现接近零的排队时延和数据包丢失. 例如ExpressPass[53]，pHost[54]，NDP[55]，Homa[56]等工作. 这类拥塞控制的主要思想是以“先请求再分配”方式运行的主动传输，即显式分配瓶颈链路的带宽并主动防止拥塞[53]. 因此能够达到较好的延时和吞吐性能. 这些方案通常让每条流在启动后的第1个RTT内线速传输数据包，后续的传输将显式分配带宽. 在ExpressPass中，接收端收到新流数据包后，通过控制反馈的控制报文（如信用等）的发送速度，以及交换机采取对控制报文精细化的限速，来分配后续RTT数据的可用带宽，能够避免端点处以及网络内的拥塞. pHost，NDP，Homa采取类似的做法，但是假设拥塞仅发生在端点处且网络内部不是瓶颈，因此仅能处理端点处的拥塞. 然而，这类主动拥塞控制中第1个RTT的数据包由于线速发送也可能导致网络内拥塞的产生[57]. 接收端驱动的主动拥塞控制需要接收端能够在为大量发送端发送控制报文的同时保证线速的性能，实现代价高，但尚未有在数据中心部署的案例.
Cheng等人[45]提出的PCN使用接收端观察到的接收速率指导发送端的部分速率调节，是专为无丢失以太网设计的拥塞控制算法. 其能够较快收敛，避免了类似DCQCN，TIMELY等的启发式调节，减少了PFC的触发. PCN指出拥塞流的接受速率是拥塞流能够通过网络瓶颈的最大速率. PCN的接收端将周期内拥塞流的接收速率直接通过CNP捎带给发送端，发送端将该接受速率作为新的发送速率. 但是在严重拥塞和队头阻塞情况下，交换机中积压的数据包队列可能仍需要较长时间才能消减，难以从根本上缓解队头阻塞问题. 此外，PCN需要同时修改交换机和网卡，其交换机和端主机耦合的拥塞探测机制在不同网络配置下可能存在不准确性和需要参数调优.
RCC[58]指出传统数据中心中大多数接收端驱动的方法默认拥塞发生在最后一跳却无法有效应对网内拥塞. 因此，RCC根据最后一跳利用率来区分网内拥塞和最后一跳拥塞，并采用不同的处理方式. 对最后一跳拥塞，根据链路带宽和流数量可以直接计算出每流的可用带宽；对网内拥塞利用比例-积分-微分（proportion-integration-differentiation，PID）控制器进行基于延时绝对差值和延时梯度的迭代式调节. 与RoCC在交换机上使用PI控制器基于队长计算速率不同，RCC基于RTT参数进行发送窗口的迭代计算无需网络内设备的特殊支持. RCC可以对最后一跳拥塞在1个RTT内实现快速收敛，但仍存在接收端网卡硬件设计复杂等问题.
3.3 多路径负载均衡
近年来，数据中心无丢失以太网在早期数据中心网络负载均衡研究基础之上，发展出了基于交换机的负载均衡方案和基于端侧的负载均衡方案.
1） 基于交换机的负载均衡
根据多路径负载均衡决策的粒度，已有研究工作可以分为数据包、flowlet等级别的负载均衡机制. 2017年，Ghorbani等人[59]提出了DRILL，DRILL在每个交换机上根据本地队列占用情况和随机算法对每个数据包决策来分配负载，能够实现细粒度、均衡的各端口队列长度，更好地应对数据中心突发流量. 但是，DRILL为传统TCP/IP协议流量设计，需要端侧协议栈配合解决数据包乱序问题.
几乎与DRILL同一时期，Alizadeh等人[60]提出了CONGA和LetFlow[61]，巧妙利用TCP窗口机制自然形成的子流单元flowlet作为负载均衡的决策粒度，交换机通过检测流量之间的到达间隔来识别flowlet，每个flowlet的数据包走同一路径，可以带来较少的数据包乱序. 其中，CONGA专门针对叶脊型的网络拓扑结构设计，在2层交换机之间交换链路信息，架顶交换机为flowlet选择链路利用率低的路径；LetFLow则是CONGA的进一步优化，指出flowlet的大小具有一定的弹性，可以通过对每个flowlet随机选路的方式应对网络中出现的拓扑不对称等情况，相比CONGA具有更低的交换机开销.
与TCP流量不同，无丢失以太网中RDMA流量将产生很少的flowlet，大幅减少了使用flowlet进行路径选择的机会. 但是，逐包负载均衡带来的乱序将极大影响RDMA的吞吐量性能，因此提出了Conweave[62]. 源端 ToR层可编程交换机负责持续监控路径延迟并在检测到拥塞时重路由，目的端借助于ToR层可编程交换机队列的暂停/恢复功能，在数据平面为重路由的流维护一个正常队列和一个乱序队列，通过控制2个队列的开闭来实现数据包最终按顺序发送. 由于Conweave全部在网内交换机实现，端侧RDMA网卡对Conweave的重路由和乱序重组操作无感知，保证了RDMA吞吐量性能和良好的负载均衡效果.
2） 基于端侧的负载均衡
基于端侧的负载均衡方案以端侧主动多径调度和端侧被动重路由为主要思想.
2015年，He等人[63]提出了Presto，将多路径负载平衡功能实现在网络边缘的虚拟交换层（hypervisor），从而无需改动网络硬件设备. Presto将流量划分成64 KB等大小的块（flowcell）并主动散射流量，利用网络拓扑中的对称性来确保1对主机之间的所有路径上负载均匀，但是其需要在虚拟交换层进行数据分块和重排，以及利用网络集中控制器的调度解决拓扑不对称导致的负载分布偏差的问题.
2018年，Lu等人[64]提出了专为无丢失以太网设计的MP-RDMA，借鉴TCP的多路传输协议MPTCP[65]的思想，端侧RDMA网卡支持主动从多个路径发送数据包. 通过多路径ACK时钟机制，为所有路径维护一个拥塞窗口，基于逐包ACK捎带的路径信息，以拥塞感知的方式分配流量，而无需维护每个路径的状态. 通过乱序感知的路径选择机制，控制乱序交付数据包的程度，从而最小化与其相关的元数据，进一步降低RDMA网卡内存开销. 但是，目前商用RDMA网卡还未支持多路径传输.
Hu等人[66]提出了无丢失以太网中PFC感知的端侧被动路由方案Proteus，指出在部署PFC的无丢失以太网中，链路利用率、端到端的ECN/RTT、交换机局部队长等信号均不能够独自准确反映PFC暂停下的路径状态，因此，提出通过使用多级信号的组合（如链路负载、队列长度、RTT和ECN等），检测三元路径状态（拥塞、不拥塞、待定）以做出初始路由决策，并利用亚RTT级信号（如交换机中累积停留时间）反映瞬时的PFC暂停，当检测出网络中PFC触发时及时重路由并尽量避免乱序. 总体而言，端侧重路由的方法一般需要RTT级别的响应时间才能被动地调整决策，不能提前避免网络内热点的发生.
3.4 无丢失以太网流量管理小结
无丢失以太网的流量管理除了需要解决链路层流量控制的负面问题，还需要满足数据中心时延敏感业务的低时延需求以及吞吐敏感业务的吞吐量要求，因此其技术发展受数据中心传统以太网影响很大. 例如，无丢失以太网早期技术路线以可扩展性高的拥塞控制算法为主，从沿用传统拥塞信号ECN和RTT，到利用先进遥测技术INT，然后近年来才发展为根据无丢失以太网的自身特性量身定制拥塞探测信号与拥塞控制算法等. 其中交换机驱动的拥塞控制和接收端驱动的主动拥塞控制部署代价较高，需要对现有交换机和硬件网卡做复杂的修改，较难适用于高速可扩展的无丢失以太网. 此外，近年来随着网络带宽增加以及网络路径数量增多，多路径负载均衡也开始受到重视，并发展出了基于端侧和交换机的解决方案. 表2和表3分别总结对比了无丢失以太网拥塞控制算法和流量负载均衡相关工作.
表 2 无丢失以太网主要拥塞控制算法的特点对比Table 2. Features Comparison of Main Congestion Control Algorithms in Lossless Ethernet表 3 无丢失以太网主要负载均衡方案的特点对比Table 3. Features Comparison of Main Load Balancing Schemes in Lossless Ethernet分类 方案 粒度 乱序程度 功能 可部署性 基于交换机 DRILL[59] 数据包 高 需要网络控制器 需要修改交换机和
软件协议栈CONGA[60] Flowlet 低 支持非对称拓扑 部分商用交换机支持 LetFlow[61] Flowlet 低 支持非对称拓扑 部分商用交换机支持 Conweave[62] 子流 无 支持非对称拓扑 仅需修改ToR层交换机 基于端侧 Presto[63] Flowcell 高 需要网络控制器 需要修改软件协议栈 MP-RDMA[64] 数据包 低 支持非对称拓扑 需要修改RDMA网卡 Proteus[66] 数据包 低 支持非对称拓扑 需要修改RDMA网卡 4. 趋势与展望
数据中心与高性能计算应用场景逐渐融合，需要统一的流量管理架构. 无丢失以太网发展于数据中心，InfiniBand发展并广泛应用于高性能计算，二者本质上都属于高速互联网络. 但由于二者承载应用、发展历史等的不同，形成了不同的流量管理技术路线. 但是，近年来随着数据中心的规模化发展和深度学习等人工智能方向的兴起，二者对底层基础设施的需求呈现重叠乃至融合的趋势. 例如，数据中心逐渐大规模部署GPU等高性能计算设备以支撑搜索推荐、生成式AI等人工智能应用，开始参考高性能计算领域普遍采用的MPI集合通信库等，使用NVIDIA集合通信库（NVIDIA collective communications library，NCCL）[67]、DeepSpeed框架[68]等进行大规模并行训练并针对GPU进行优化以支持更大规模的人工智能模型和更加高效的并行加速. 近年来，基于无丢失以太网的数据中心也开始探索与InfiniBand中类似的流量管理技术路线. 例如，Lu等人[64]提出的MP-RDMA、Shalev等人[69]提出的SRD等技术都提出采用多路负载均衡的思想来暂时缓解网络内的拥塞；Goyal等人[70]提出的BFC尝试逐跳为每流分配队列并进行控制，解决队头阻塞以及端到端协议无法控制短流的问题；IEEE 802.1 Qcz[71]提出的在无丢失以太网中支持高性能计算、分布式存储以及数据中心应用的动态拥塞隔离方案；此外，由超微半导体、博通、微软等多家工业界公司联合发起的超以太网联盟（Ultra Ethernet Consortium，UEC）提出UEC传输协议[72]，将综合多路径散射、拥塞控制等多种机制，特别为人工智能和高性能计算应用提供最佳性能的同时保留以太网的优势. 在如今数据中心与高性能计算逐渐融合的趋势下，更需要对流量管理架构展开系统性研究，研究不同流量管理策略的适用性、交互性以及如何组合不同的流量管理策略，提出统一的流量管理方法.
1）面向机内拥塞和网内拥塞的联合流量管理. 流量管理研究的传统观点是拥塞主要发生在网络结构内. 然而，如今数据中心、高性能计算集群中链路带宽迅速增长，从40 Gbps，100 Gbps发展为200 Gbps乃至400 Gbps等，与之相比，主机内PCIe总线带宽等资源发展速度却相对缓慢，这导致了主机内拥塞问题凸显，即支持NIC和CPU/内存之间数据交换的主机网络内出现拥塞. 值得注意的是，主机内PCIe总线网络通常也是无丢失的（使用基于信用的流量控制机制），因此传统无丢失网络的边界扩展到了主机内部. 不断增加的线路速率和存写密集型工作负载给每数据包的软件/硬件处理资源带来压力，导致CPU、DRAM带宽和PCIe出现瓶颈，从而在NIC和主机堆栈中形成队列，易发生端主机拥塞. 来自康奈尔大学、谷歌等的研究人员在2023年SIGCOMM会议上提出了HostCC[73]，该方案能收集主机拥塞信号（如PCIe互联的I/O控制器的缓存占用大小），捕获主机拥塞的精确时间和位置，引入亚RTT粒度的主机本地拥塞响应，在网络流量和主机本地流量之间分配主机资源，减少了主机上的排队，从而提高了应用程序吞吐量和尾部延迟性能. HostCC需要网卡支持高精度的时间戳功能以提供准确的延时测量，避免端主机处理时延抖动的干扰. HostCC是主要针对主机内拥塞的研究工作. 但是，随着近年来主机内NVLink/NVSwitch[74]等新型互联技术的发展，主机内网络的交换结构呈现复杂化趋势，如何对主机内网络流量的瓶颈定位，如何应对主机内复杂拥塞、主机内亚RTT粒度的流量管理与已有针对网络内流量管理之间是否存在交互影响以及二者如何协同工作等，有待进一步深入研究.
2）面向领域应用的流量管理. 研究表明，深度学习等人工智能方法的训练通信开销甚至占据了训练迭代时间的主要部分[75-78]，并且具有典型的通信-计算迭代的周期性特征. 考虑到这种应用特征，传统拥塞控制追求的公平性对于机器学习工作负载可能并不友好，不公平的拥塞控制反而可能加速机器学习工作负载[79-80]. 例如，通过调整传输协议的公平性参数或者网络链路感知的任务调度，使得同时共享链路的任务的通信和计算周期交错，从而最大化链路利用率，提高通信阶段的吞吐量性能. Katebzadeh等人[81]指出数据分析、图形处理等各种数据中心机器学习工作负载对网络带宽会表现出不同的敏感度：对于某些工作负载，即使可用带宽的小幅减少也会导致完成时间的显著增加；而对于其他工作负载，完成时间可能对可用带宽并不敏感，因此提出设计了一种应用程序感知的带宽分配框架Saba，根据应用程序的敏感性分配网络带宽，线下根据程序画像定量确定敏感度并与运行时带宽分配相结合，同时无需修改网络硬件. 此外，一些工作提出使用流水线[75]或优先参数传输[82-84]的方法来重叠单个任务的计算和通信阶段以提高网络资源利用率和降低网络传输时间等. 例如，TicTac[82]通过对底层计算图的关键路径分析来导出接近最优的参数传输时间表并强制执行网络传输顺序，从而允许计算和通信的最大重叠，并防止传统上由于参数传输的随机顺序而导致的掉队任务. 总之，通过对领域应用特征系统性的认识和理解，设计面向领域应用的流量管理方案来高效提升应用性能具有很大前景，有待进一步研究.
3）光电混合无丢失网络的流量管理. 近年来，构建光电混合网络成为提升大规模数据中心网络整体运算效能的重要趋势. 谷歌公司提出了Jupiter组网架构[85]，并在多年迭代发展中逐渐引入光交换技术，支持在网络中创建专用光通道连接数据中心内的不同部分，满足特定场景下大带宽和低延迟需求. Jupiter通过SDN协同光电2层优化混合网络组网，解决了高速互联扩容问题. 微软公司也提出了数据中心Sirius组网架构[86]，引入光交换以及流量切换控制、快速调度协议、拓扑和路由优化等技术. 2021年，阿里巴巴公司提出一种基于快速光开关的数据中心光交换网络[87]，通过采用标签控制和光数据流量控制算法，进一步降低网络时延和丢包率. 然而，现有光电混合无丢失网络的流量管理仍面临诸多挑战，例如现有光电混合无丢失网络的路由算法大多存在循环缓冲区依赖、易加剧PFC导致的网络死锁问题. 为此，Zhao等人[88]提出将光电混合网络转化为一个虚拟的层级网络，然后借助虚拟层级构造上下路由来消除死锁；此外，由于光交换的切换调度复杂，业务流量在线规划变得更加困难，因此上海交通大学的研究人员提出利用竞争比来分析不同物理互连架构性能的思路，设计鲁棒性拓扑优化方案[89-90]，使得一种光交换机配置方式能够同时应对多种流量方案. 目前，光电混合网络是无丢失网络的重要发展方向，但其流量管理需要结合光交换技术的特点对其带来的新挑战深入研究.
5. 总 结
为实现低时延、无数据丢失的网络传输需求，无丢失网络近年在高性能计算、数据中心等领域迅速发展. 但是，保证无丢失特性的链路层流量控制带来的负面影响（队头阻塞、死锁、不公平等）成为构建大规模无丢失网络的挑战. 因此，流量管理成为提升无丢失网络可扩展性的关键技术. 流量管理通过对流量进行合理的带宽分配等手段，避免链路层流量控制的负面影响，提升应用传输性能. 本文分别从2类无丢失网络流量管理的视角，按流量管理技术路线以及驱动的位置进行分类，分析总结对应的优势以及局限性，理解2类无丢失网络采用不同技术路线的原因. 最后讨论了无丢失网络流量管理的设计空间和发展趋势，为后续的研究奠定基础.
作者贡献声明：张乙然提出了论文思路并进行论文撰写；王尚广和任丰原提出意见并修改论文.
-
![]()
图 7 面向芯粒互联的Reed-Solomon码译码器架构
Figure 7. Reed-Solomon decoder architecture for Chiplet interconnection
表 1 国内外Chiplet互联协议对比
Table 1 Comparison of Interconnection Protocols for Domestic and International Chiplet
协议名称 UCIe 小芯片接口总线技术要求 芯粒互联接口标准 国家 美国 中国 中国 制定者 UCIe联盟 中国计算机互连技术联盟（CCITA） 中国芯粒产业联盟（CCLL） 发布年份 2022 2022 2023 应用场景 C2C，C2IO C2M（后续）、C2C、C2IO、C2O C2C，C2IO 协议层次 协议层、D2D适配层、物理层 数据链路层、适配层、物理层 协议层、链路层、物理层 兼容性 支持PCIe6.0、CXL2.0、流协议 支持flit包格式传输 支持AXI4.0、CXL3.0、原生模式 链路报文格式（大小等）/B 68，256 70，256 128，256，384，512，640 物理层种类 并行单端 并行单端、串行单端、串行差分 串行差分 传输速率/GTps 4，8，12，16，24，32 2.5，5，8，16，32 32，64，128 接口位宽 K×N 16×2×N（并行）、4×N（串行） 8×N 传输距离/mm ≤10 ≤25 ≤50 误码率 1E－15(传输速率≥12GTps)
1 E－27(传输速率≤8GTps)1 E－15 1 E－15，1 E－12，1 E－9 延迟/ns ≤2 ≤13 ≤6 功耗/（pJ/b） 0.25~1.25 1.5，2.5 2.5 封装方式 2D，2.5D 2D，2.5D 2D，2.5D 
下载: 导出CSV
表 2 典型互联架构对比
Table 2 Comparison of Typical Interconnected Architectures
类别 多芯粒架构 中心IO芯粒架构 侧接口芯粒架构 应用场景 高性能计算、人工智能加速器、大数据处理等 数据中心、
高性能计算等高速数据传输、高性能GPU等 典型产品 EPYC ( 7001 )，Sapphire Rapids，Emerald Rapids等EPYC ( 7002 ，7003 ，9004 )，MI300，Ponte Vecchio等昇腾910、RX7000、Ampere等 互联能力 最弱 最强 适中 通信效率 较低 最高 较低 生产成本 最低 最高 较高 布线密度 最高 低 低 面积大小 最大 较小 最小 延迟 最高 低 低 功耗 最高 低 低
下载: 导出CSV
表 3 芯粒互联容错技术对比
Table 3 Comparison of Fault Tolerant Technologies for Chiplet Interconnection
类别 容错编码 容错拓扑 容错路由 适用场景 芯粒间数据传输 集成芯片的芯粒互联 集成芯片的芯粒互联 容错方法 添加冗余信息 采用高连接性网络，
添加冗余网络执行路由策略，绕开故障区域 容错性能 编码增益高 容错率高 故障规避率高 代价 牺牲编码效率 增加冗余节点和链路 增加硬件开销 延迟 低 低 高
下载: 导出CSV
表 4 典型互联芯粒对比
Table 4 Comparison of Typical Interconnected Chiplets
类别 可编程互联芯粒 路径可编程互联芯粒 专用互联芯粒 应用场景 云计算、大数据处理等 高性能计算、AI计算等 服务器架构、GPU集群 灵活性 最高 适中 最低 设计复杂度 最高 适中 最低 设计费用 最高 适中 最低 设计周期 最长 适中 最短 设计风险 最高 适中 最低 规模化生产成本 最高 适中 最低 面积大小 最大 较小 最小 性能 较好 良好 优异 延迟 最高 适中 最低 功耗 最高 适中 最低
下载: 导出CSV
-
[1] Naffziger S, Beck N, Burd T, et al. Pioneering Chiplet technology and design for the AMD EPYC™ and Ryzen™ processor families: Industrial product[C]//Proc of the 48th ACM/IEEE Annual Int Symp on Computer Architecture (ISCA). Piscataway, NJ: IEEE, 2021: 57−70
[2] Loh G H, Naffziger S, Lepak K. Understanding Chiplets today to anticipate future integration opportunities and limits[C]//Proc of the 24th Design, Automation & Test in Europe Conf & Exhibition (DATE). Piscataway, NJ: IEEE, 2021: 142−145
[3] Feng Yinxiao, Ma Kaisheng. Chiplet actuary: A quantitative cost model and multi-Chiplet architecture exploration[C]//Proc of the 59th ACM/IEEE Design Automation Conf. Piscataway, NJ: IEEE, 2022: 121−126
[4] Suggs D, Subramony M, Bouvier D. The AMD ‘zen 2’ processor[J]. IEEE Micro, 2020, 40(2): 45−52 doi: 10.1109/MM.2020.2974217
[5] Sharma D D, Pasdast G, Qian Zhiguo, et al. Universal Chiplet interconnect express (UCIe): An open industry standard for innovations with Chiplets at package level[J]. IEEE Transactions on Components, Packaging and Manufacturing Technology, 2022, 12(9): 1423−1431 doi: 10.1109/TCPMT.2022.3207195
[6] Liao Jie, Jiao Bo, Zhang Jinshan, et al. A scalable die-to-die interconnect with replay and repair schemes for 2.5D−3D integration[C]//Proc of the 56th IEEE Int Symp on Circuits and Systems (ISCAS). Piscataway, NJ: IEEE, 2023: 57−70
[7] Meng Hui, Zhao Qian, Yoshida T. A study of reconfigurable switch architecture for Chiplets interconnection[C]//Proc of the 10th International Symposium on Computing and Networking Workshops (CANDARW), NJ: IEEE, 2022: 69−75
[8] 陈桂林,王观武,胡健,等. Chiplet封装结构与通信结构综述[J]. 计算机研究与发展,2022,59(1):22−30 doi: 10.7544/issn1000-1239.20200314 Chen Guilin, Wang Guanwu, Hu Jian, et al. Survey on Chiplet packaging structure and communication structure[J]. Journal of Computer Research and Development, 2022, 59(1): 22−30 (in Chinese) doi: 10.7544/issn1000-1239.20200314
[9] 蒋剑飞,王琴,贺光辉,等. Chiplet技术研究与展望[J]. 微电子学与计算机,2022,39(1):1−6 doi: 10.3969/j.issn.1000-7180.2022.1.wdzxyjsj202201001 Jiang Jianfei, Wang Qin, He Guanghui, et al. Research and prospect on Chiplet technology[J]. Microelectronics & Computer, 2022, 39(1): 1−6 (in Chinese) doi: 10.3969/j.issn.1000-7180.2022.1.wdzxyjsj202201001
[10] 李应选. Chiplet的现状和需要解决的问题[J]. 微电子学与计算机,2022,39(5):1−9 doi: 10.3969/j.issn.1000-7180.2022.5.wdzxyjsj202205001 Li Yingxuan. The state-of-the-art of Chiplet and problems need be solved[J]. Microelectronics & Computer, 2022, 39(5): 1−9 (in Chinese) doi: 10.3969/j.issn.1000-7180.2022.5.wdzxyjsj202205001
[11] Liu Yafei, Li Xiangyu, Yin Shouyi. Review of Chiplet-based design: System architecture and interconnection[J]. Science China Information Sciences, 2024, 67(10): 200401: 1−200401: 20
[12] 解维坤,蔡志匡,刘小婷,等. 芯粒测试技术综述[J]. 电子与封装,2023,23(11):110101:1−110101:11 Xie Weikun, Cai Zhikuang, Liu Xiaoting, et al. Overview of Chiplet testing technology[J]. Electronics &Packaging, 2023, 23(11): 110101: 1−110101: 11 (in Chinese)
[13] 集成芯片与芯粒技术白皮书)[EB/OL]. 2023 [2024-06-09]. https://www.gitlink.org.cn/zone/iChips/Source/12 White paper on integrated Chip and Chiplet technology [EB/OL]. 2023 [2024-06-09]. https://www.gitlink.org.cn/zone/iChips/Source/12 (in Chinese)
[14] Universal Chiplet interconnect express. Universal Chiplet interconnect express (UCIe) specification revision 1.1 [EB/OL]. (2023-07-10) [2024-06-10]. https://www.uciexpress.org/ucie-1-1-white-paper-download
[15] 中国电子工业标准化技术协会. T/CESA 1248—2023 小芯片接口总线技术要求[S]. 北京:中国电子工业标准化技术协会,2023 China Electronics Standardization Association. T/CESA 1248—2023 Techical Requirement for Chiplet Interface Bus[S]. Beijing: China Electronics Standardization Association, 2023 (in Chinese)
[16] 中国 Chiplet 产业联盟. T/ZGTXXH096−2024 芯粒互联接口标准[EB/OL]. 2022−12 [2024-06-12]. http://www.iiisct.com/smart/upload/ CMS1/202303/ACC1.0.pdf Chiplet Industry Alliance of China. T/ZGTXXH096−2024 Advanced cost-driven Chiplet interface [EB/OL]. 2022−12 [2024-06-12]. http://www.iiisct.com/smart/upload/CMS1/202303/ACC1.0.pdf(in Chinese)
[17] Gomes W, Khushu S, Ingerly D B, et al. 8.1 lakefield and mobility compute: A 3Dstacked 10nm and 22FFL hybrid processor system in 12×12mm2, 1mm package-on-package[C]//Proc of the 67th ISSCC. Piscataway, NJ: IEEE, 2020: 144−146
[18] Beck N, White S, Paraschou M, et al. Zeppelin’: An SoC for multichip architectures[C]// Proc of the 65th ISSCC. Piscataway, NJ: IEEE, 2018: 40−41
[19] Naffziger S, Lepak K, Paraschou M, et al. 2.2 AMD Chiplet architecture for high-performance server and desktop products[C]//Proc of the 67th ISSCC. Piscataway, NJ: IEEE, 2020: 44−45
[20] Liao Heng, Tu Jiajin, Xia Jing, et al. Ascend: A scalable and unified architecture for ubiquitous deep neural network computing[C]//Proc of the 27th IEEE Int Symp on High-Performance Computer Architecture (HPCA). Piscataway, NJ: IEEE, 2021: 789−801
[21] Bossert M, Schulz R, Bitzer S. On hard and soft decision decoding of BCH codes[J]. IEEE Transactions on Information Theory, 2022, 68(11): 7107−7124 doi: 10.1109/TIT.2022.3184168
[22] Valls J, Torres V, Canet M J, et al. A test vector generation method based on symbol error probabilities for low-complexity Chase soft-decision Reed-Solomon decoding[J]. IEEE Transactions on Circuits and Systems I: Regular Papers, 2019, 66(6): 2198−2207 doi: 10.1109/TCSI.2018.2882876
[23] Zhang Xinmiao. VLSI architectures for Reed-Solomon codes: classic, nested, coupled, and beyond[J]. IEEE Open Journal of Circuits and Systems, 2020, 1: 157−169 doi: 10.1109/OJCAS.2020.3019403
[24] Gao Jiajing, Zhang Wei, Liu Yanyan, et al. High-performance concatenation decoding of Reed-Solomon codes with SPC codes[J]. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2021, 29(9): 1670−1674 doi: 10.1109/TVLSI.2021.3097155
[25] Guo Jianzhong, Li Ruoxi, Zhang Yuan, et al. Hard-decision decoding algorithms for LDPC codes based on matching pursuit[J]. IEEE Communications Letters, 2024, 28(3): 454−457 doi: 10.1109/LCOMM.2023.3340560
[26] Arikan E. Channel Polarization: A method for constructing capacity achieving codes for symmetric binary-input memoryless channels[J]. IEEE Transactions on Information Theory, 2009, 55(7): 3051−3073 doi: 10.1109/TIT.2009.2021379
[27] Wang Ying, Han yinhe Zhang lei, et al. Economizing TSV resources in 3-D network-on-chip design[J]. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2014, 23(3): 493−506
[28] Fu Binzhang, Han Yinhe, Li Huawei, et al. Zonedefense: A fault-tolerant routing for 2-d meshes without virtual channels[J]. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2013, 22(1): 113−126
[29] Xiang Dong, Chakrabarty K, Fujiwara H. Multicast-based testing and thermal-aware test scheduling for 3D ICs with a stacked network-on-chip[J]. IEEE Transactions on Computers, 2015, 65(9): 2767−2779
[30] Ni Tianming, Xu Qi, Huang Zhengfeng et al. A cost-effective TSV repair architecture for clustered faults in 3-D IC[J]. IEEE Transactions on Computer-aided Design of Integrated Circuits and Systems, 2020, 40(9): 1952−1956
[31] Tosun S, Ajabshir V B, Mercanoglu O, et al. Fault-tolerant topology generation method for application-specific network-on-chips[J]. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2015, 34(9): 1495−1508 doi: 10.1109/TCAD.2015.2413848
[32] Ren Pengju, Ren Xiaowei, Sane S, et al. A deadlock-free and connectivity-guaranteed methodology for achieving fault-tolerance in on-chip networks[J]. IEEE Transactions on Computers, 2016, 65(2): 353−366 doi: 10.1109/TC.2015.2425887
[33] Chen Y, Chang E, Hsin H, et al. Path-diversity-aware fault-tolerant routing algorithm for network-on-chip systems[J]. IEEE Transactions on Parallel and Distributed Systems, 2017, 28(3): 838−849 doi: 10.1109/TPDS.2016.2588482
[34] 王浩,王勇,冯长磊,等. 宇航高可靠高速互联芯粒:中国,CN202311597700.9[P/OL]. 2024-03-29 [2024-06-15]. https://d.wanfangdata.com.cn/patent/ChhQYXRlbnROZXdTMjAyNDExMjIxNjU4MjISEENOMjAyMzExNTk3NzAwLjkaCDduM3R0YjM5 Wang Hao, Wang Yong, Feng Changlei, et al. Aerospace high reliability and high-speed interconnection Chiplets. China, CN202311597700.9 [P/OL] . 2024-03-29 [2024-06-15]. https://d.wanfangdata.com.cn/patent/ChhQYXRlbnROZXdTMjAyNDExMjIxNjU4MjISEENOMjAyMzExNTk3NzAwLjkaCDduM3R0YjM5(in Chinese)
[35] IEEE Computer Society. IEEE 1149.1−2013 Test Technology Standards Committee. Test Access Port and Boundary-scan Architecture[S]. Piscataway, NJ: IEEE, 2013
[36] IEEE Computer Society. IEEE 1500−2005 Testability Method for Embedded Core-based Integrated Circuits[S]. Piscataway, NJ: IEEE, 2005
[37] IEEE Standards Association. IEEE 1687−2014 Access and Control of Instrumentation Embedded within A Semiconductor Device[S]. Piscataway, NJ: IEEE, 2014
[38] IEEE Computer Society. IEEE 1838−2019 Test Access Architecture for Three-dimensional Stacked Integrated Circuits[S]. Piscataway, NJ: IEEE, 2020
[39] Abdennadher S. Testing inter-Chiplet communication interconnects in a disaggregated SoC design[C]//Proc of the IEEE Int Conf on Design & Test of Integrated Micro & Nano-Systems (DTS). Piscataway, NJ: IEEE, 2021 [2024-06-13]. https://xplorestaging.ieee.org/document/9498132
[40] Chandra A, Khan M, Patidar A, et al. A Case study on IEEE 1838 compliant multi-Die 3DIC DFT implementation[C]//Proc of the IEEE International Test Conference (ITC). Piscataway, NJ: IEEE, 2023: 11−20
[41] McLaurin T, Cron A. Applying IEEE test sandards to multidie designs[J]. IEEE Design & Test, 2022, 39(5): 7−16
[42] Zhang Zhen, Wei Jinghe, Yin Yujia, et al. An improved test structure of boundary scan designed for 2.5D integration[C]//Proc of the 8th Int Conf on Integrated Circuits and Microsystems (ICICM). Piscataway, NJ: IEEE, 2023: 643−648
[43] Syed U S, Chakrabarty K, Chanadra A, et al. 3D-Scalable Adaptive Scan (3D-SAS)[C]//Proc of the IEEE Int 3D Systems Integration Conf (3DIC) . Piscataway, NJ: IEEE, 2012: 1−6
计量
- 文章访问数: 69
- HTML全文浏览量: 14
- PDF下载量: 33
