1. 项目概述为什么我们需要粗粒度可重构处理器在嵌入式系统和移动计算领域我们一直在性能、功耗和灵活性之间走钢丝。传统的路子无非两条要么用专用集成电路ASIC性能强、功耗低但一颗芯片只能干一件事流片成本高算法一升级就可能过时要么用通用处理器GPP或数字信号处理器DSP编程灵活但面对视频解码这类计算密集、数据并行的任务往往力不从心为了达到实时性能不得不拉高主频功耗就上去了。这时候可重构计算Reconfigurable Computing就成了一条有吸引力的中间路径。它的核心思想是硬件不再是“死”的而是可以在运行时根据软件任务的需求动态改变自身的结构和功能。你可以把它想象成一个乐高积木搭建的计算平台基本的处理单元PE和连接它们的线路互连网络都是可编程的。当需要做运动补偿MC时我就把积木搭成一个并行度很高的矩阵乘法器下一秒需要做反离散余弦变换IDCT了我又可以快速把积木重新排列成一个适合蝶形运算的结构。粗粒度可重构阵列CGRA是这个领域的主流。与FPGA那种比特级细粒度的可编程不同CGRA的处理单元通常是16位或32位的算术逻辑单元ALU粒度更粗。这意味着它的配置信息量更小配置速度更快更适合应对视频解码这种需要频繁在不同计算内核间切换的场景。然而早期的CGRA设计往往过于追求峰值性能忽视了配置开销带来的巨大能量损耗。你想想一个包含上百个PE的大阵列每切换一次任务就要重新灌入成千上万的配置比特这个过程中数据搬移和寄存器翻转消耗的能量有时甚至能赶上计算本身。这成了制约CGRA在能量敏感的移动设备上广泛应用的一个关键瓶颈。我们团队当时接到的任务就是设计一个面向多标准视频解码的粗粒度可重构处理单元RPU核心目标就俩字能效。不仅要跑得快更要在有限的功耗预算下跑得久。最终流片的芯片一个高性能版本REMUS_HPP在200MHz下能解码1080p30fps的H.264视频功耗仅280mW另一个低功耗版本REMUS_LPP在75MHz下实现同样帧率功耗更是低至24.5mW。这背后是一系列从架构到电路级别的协同设计而不仅仅是工艺进步的功劳。1.1 核心需求解析视频解码的计算特征与挑战要设计一个高效的加速器首先得把负载吃透。视频解码流程虽然标准各异H.264, MPEG-2, AVS等但核心步骤大同小异熵解码、反量化IQ、反变换IDCT、运动补偿MC/帧内预测、重建、去块滤波Deblocking。我们对一个典型的H.264解码任务在通用处理器上做了剖析发现超过75%的计算量都集中在MC、Deblocking和IDCT/IQ这几个模块。它们有一个共同特点面向块Block或宏块Macroblock的规则数据并行计算。以运动补偿为例为了预测当前块需要从参考帧中取出一个或多个候选块进行加权求和。这个操作本质上是对内存中一片连续的图像数据做大量的乘加运算SAD, SATD等数据依赖关系简单非常适合在PE阵列上展开并行。去块滤波虽然逻辑稍复杂涉及边界判断和滤波强度选择但其核心操作仍然是针对像素行/列的加减、比较和饱和运算具有很高的数据局部性和并行潜力。这就为我们指明了设计方向RPU的架构必须高效支持这种规则的数据并行、以乘加为核心的算术运算、以及频繁的局部数据交换。同时视频解码是流水线作业不同模块如MC和Deblocking理论上可以并行执行以提升吞吐率。因此架构还需要具备一定的任务级并行能力。另一个容易被忽视但至关重要的挑战是配置效率。视频解码过程中算法内核切换频繁。例如处理完一个宏块的MC紧接着就要处理其IDCT然后可能是Deblocking。如果每次切换都需要数百甚至上千个周期来重新配置整个PE阵列那么宝贵的计算资源将大量时间浪费在“等待”上有效吞吐率大打折扣能效比自然难看。因此如何减少配置信息量、加速配置过程成为提升整体能效的关键。2. 架构核心设计如何打造一个高能效的RPU基于上述分析我们提出了RPU的整体架构。它不是一个孤立的计算阵列而是一个包含完整数据通路和配置通路的协处理器。其核心思想是将计算密集部分卸载到可重构阵列上而控制密集、不规则的部分如熵解码、码流解析仍由主控处理器如ARM处理。RPU的架构框图清晰地划分了这两条路径。2.1 数据通路异构PE阵列与创新的互连网络数据通路的核心是一个可重构处理单元阵列PEA。我们并没有采用常见的同构大规模阵列而是基于视频解码的算子特征设计了一个异构阵列。2.1.1 处理单元PE的精细化设计每个PE的核心是一个16位算术逻辑单元ALU支持26种操作包括加、减、逻辑运算、移位、比较、饱和、绝对值等。关键洞察来自于对H.264/MPEG-2/AVS解码代码的静态和动态分析乘法及相关操作如乘加的出现概率总和不到7%。在视频解码中乘法主要用于运动补偿中的像素插值涉及滤波系数以及变换中的少量系数乘法大部分计算是加、减、比较和饱和操作。因此我们做了一个大胆的优化并非所有PE都配备硬件乘法器。在由4个RCAs可重构单元阵列组成的PEA中只有位于第二行的PE集成了16x16定点乘法器。这样整个芯片的乘法器数量从256个减少到32个。你可能担心这会影响性能但由于乘法操作本身占比低且可以通过编译调度将乘法任务集中映射到这些“富资源”PE上实际性能损失微乎其微。但带来的收益是巨大的PE的总面积减少了约80%。在芯片设计里面积就是成本也是静态功耗的主要来源之一。此外PE的配置寄存器设计也考虑了功耗。我们使用5位固定长度的操作码OPCODE。通过分析大量解码任务的配置序列我们优化了OPCODE的编码使得在典型任务切换时配置比特的跳变0-1或1-0概率最小化且分布均匀。这直接降低了配置网络上的动态功耗。2.1.2 线交换网格互连LSMC在灵活性与面积间取得平衡PE之间的互连网络是CGRA面积和延迟的大头。传统的全互连Full Mesh虽然灵活但每个PE都要与所有I/O端口相连随着阵列规模增大连线数量和开关数量呈平方级增长导致布线拥塞、面积膨胀、功耗激增。我们提出了线交换网格互连Line-Switched Mesh Connect, LSMC。其核心思想是化“全连接”为“线连接”。具体来说我们将一个RCA内的8x8 PE组织成8行。在任一时刻只有特定的一行PE通过一个共享的I/O总线与外部256位宽的FIFO二级FIFO直接相连。PE行内的数据交换则通过一个高效的层内网格网络完成。当需要访问不同行的数据时可以通过配置动态切换哪一行PE连接到I/O总线。这样做的好处非常明显大幅减少了长距离、高扇出的全局连线。实际综合评估显示在阵列规模较大时LSMC的互连部分面积相比全互连方案可减少超过50%。有人可能会问这会不会成性能瓶颈我们通过将MC、Deblocking、IDCT等核心内核映射到两种互连结构上进行周期精确仿真发现LSMC带来的性能损失不超过5%。这是因为视频解码的数据访问模式具有很强的空间局部性连续的数据块往往被映射到相邻的PE行上LSMC结构完全能够满足其带宽需求。用面积换来的能效提升是极其划算的。2.1.3 层次化存储结构匹配数据流光有计算单元不够还得喂得饱数据。RPU设计了多级缓冲存储结构来匹配PE阵列的吞吐率二级FIFO每个RCA配有输入和输出二级FIFO深度分别为32和4宽度为256位对应16个16位数据。这用于缓冲从外部内存涌入的突发数据流平滑访存延迟。宏块缓冲区Macro Buffer一个128x16位的单端口内存用于RCA之间的中间结果交换。例如一个RCA处理完IDCT的结果可以暂存于此供另一个RCA进行运动补偿时读取。RCA内部内存RIM一个64x16位的双端口内存用于单个RCA内部不同计算阶段之间的数据暂存减少对外部存储的访问。交换内存EM一个128x16位的双端口内存作为两个RPU核心在双核配置中之间的共享数据交换区采用乒乓缓冲机制实现计算与数据搬运的重叠。这种层次化的存储设计确保了数据在计算单元周围高效流动避免了因等待数据而导致的PE闲置是提升硬件利用率和能效的关键。2.2 配置通路分层配置上下文HCC大幅削减配置开销如果说数据通路是肌肉那么配置通路就是神经。如何快速、低功耗地“告诉”硬件下一步要做什么是CGRA设计的灵魂。传统的CGRA配置模式可以看作“平铺式”每个任务内核Kernel对应一个完整的、独立的配置比特流Context。切换任务时需要将一整个新Context全部加载到PE的配置存储器中。这对于视频解码这种由众多小内核组成的应用来说效率极低。我们提出了分层配置上下文Hierarchical Configuration Context, HCC方案。它将配置信息抽象为三个层次核心上下文Core Context最底层包含PE的ALU操作码、层内互连配置位、数据加载/存储命令。它定义了PE阵列在一个小计算步骤中的具体形态。组上下文Group Context中间层由一系列核心上下文的索引组成。它描述了一个稍大的、数据相关的计算序列。例如一个宏块的运动补偿可能包含多个相似但数据不同的子块补偿操作它们可以使用相同的PE阵列结构核心上下文只是数据不同。组上下文通过重复调用同一个核心上下文的索引避免了重复存储和传输相同的配置信息。完整上下文Complete Context最高层由组上下文的索引和同步命令组成。它由主机处理器动态生成描述了整个任务如一帧的解码流程。HCC的优势在于极高的数据压缩率。对于H.264解码应用采用HCC后需要存储和传输的配置信息总量相比非分层方案减少了76%。这意味着配置缓存可以更小节省面积和静态功耗配置总线上的数据搬运量大幅减少降低动态功耗配置速度也更快。硬件上我们为RPU配备了专用的全局核心上下文内存GCCM和全局组上下文内存GGCM。主机处理器只需要下发轻量级的完整上下文RPU内部的配置解析器会根据索引从GGCM和GCCM中取出实际的配置位流。实测表明采用HCC后配置时间在RPU总执行时间中的占比从传统架构如XPP40的24%以上降低到了4%-13%。这意味着硬件资源有更多时间是在实实在在地做计算能效自然得到显著提升。2.3 阵列规模探索多大的PEA才够用设计初期一个关键问题是PEA到底要做多大不是越大越好面积和功耗会线性增长。我们需要找到满足性能需求的最小规模。我们的性能约束是在200MHz下能实时解码1080p视频每秒30帧每帧8160个宏块。算下来平均处理每个宏块的周期预算约为816个周期。我们以RCA的高度H固定为8匹配最小计算块4x4变化其宽度W从4到32进行周期精确仿真。仿真结果显示去块滤波Deblocking是其中最耗时的子任务。当W8时四个RCA并行工作处理一个宏块的所有子任务Pred, IDCT, DeB的总周期数开始低于816的预算。继续增大W性能提升的边际效应递减而面积开销却线性增加。当W从8增加到32时PEA面积增长超过3倍。因此8x8的RCA四个组成一个PEA被确定为最优解在满足性能目标的同时实现了硬件资源的最经济利用。实操心得架构探索中的权衡在芯片架构定义阶段这种基于周期精确仿真和面积评估的探索至关重要。不能只盯着峰值性能。我们建立了快速的SystemC模型将关键算法内核映射上去跑仿真同时集成面积预估工具。这个过程中要敢于做“非对称”的异构设计如减少乘法器也要善于利用应用的特征如数据局部性来简化互连。LSMC和HCC这两个核心创新都源于对视频解码这一特定领域负载的深刻理解而不是追求通用的、面面俱到的灵活性。在嵌入式领域“够用就好”的设计哲学往往能带来最佳的能效比。3. 从算法到硬件映射流程与编译支持再好的硬件如果没有高效的编程工具链也只是一堆硅沙。为了让算法工程师能利用RPU我们开发了一套基于C语言的编译框架。3.1 编译流程概述整个流程是源到源的前端处理使用修改版的SUIF2和Mach-SUIF工具链对标准C代码进行解析和优化。编译器会识别出其中计算密集的循环嵌套通常是视频解码的内核将其提取为数据流图DFG。剩余的控制密集型代码则被标注并保留为C代码由主控处理器执行。循环变换与映射这是最关键的一步。我们建立了一个基于多面体模型Polyhedral Model的总执行时间TET分析模型。这个模型同时考虑了配置开销、数据通信开销和计算开销。传统的映射工具往往只优化计算忽略了CGRA中巨大的配置成本。我们的工具PolyMAP将循环嵌套的映射问题转化为一个约束优化问题通过启发式算法搜索最优的循环变换如循环分块、展开、交换方案在三种开销间取得最佳平衡。测试表明相比当时先进的EPIMap和PolyCOM方法PolyMAP在PolyBench测试集和H.264内核上平均能带来22%到32%的性能提升。后端处理与代码生成优化后的DFG通过一个改进的、基于模板的子图同构映射方案映射到具体的PE阵列结构上。这个阶段会充分利用HCC的特性识别出重复的计算模式生成共享的核心上下文进一步压缩配置信息量最终生成可供RPU加载执行的配置流。3.2 映射效果以H.264解码内核为例我们将H.264解码中最关键的三个内核——IDCT、运动补偿MC和去块滤波Deblocking——映射到RPU上并与商业可重构处理器XPP40进行对。算法内核性能指标XPP40 (最坏情况)RPU (典型情况)RPU (最坏情况)IDCT周期/宏块12085102MC周期/宏块180132158Deblocking周期/宏块480305366从上表可以看出RPU在各个内核上的性能均优于XPP40。这得益于更高效的PE架构、LSMC互连带来的高数据带宽以及HCC大幅减少的配置时间。特别是在最耗时的Deblocking滤波上RPU的优化最为明显。注意事项映射的局限性我们的编译器和架构并非万能。对于控制密集型、含有大量不规则分支和回溯的算法如N皇后问题其数据流图难以高效映射到规则的PE阵列上强行映射会导致配置频繁切换和存储开销激增性能甚至可能不如通用处理器。RPU的强项在于规则数据并行和流式处理。因此在系统划分时必须由工程师或高级编译器判断将合适的任务卸载到RPU其余部分留在主控CPU。4. 芯片实现、测试与全面评估设计最终要落在硅上。我们采用TSMC 65nm LP工艺实现了三款芯片来验证RPU。4.1 芯片系列与系统集成CHAMELEON这是一个纯RPU核心的原型验证芯片用于大量算法映射和性能 profiling。RHINOCEROS (SoC)这是一个面向高性能应用的系统级芯片。它集成了两个RPU核心构成REMUS_HPP处理器、一个RPU微控制器RMC、一个主控微控制器MMC、DMA、视频预处理单元VPP负责熵解码等比特级操作以及丰富的外设。双RPU设计允许并行处理MC和Deblocking进一步提升吞吐率。REINDEER (SoC)这是一个面向低功耗便携设备的SoC。它集成了单RPU核心REMUS_LPP处理器和必要的外设主打高能效。4.2 性能与能效评估视频解码我们在真实芯片上测试了多标准视频解码性能高性能版本 (REMUS_HPP 200MHz)H.264 HP1080p稳定30 fps功耗280mW。对比XPP-III性能提升25%能效MB/s/mW提升高达14倍。对比一款专用多格式视频编解码ASIC解码性能相当但能效约为其一半。这符合预期ASIC在专用任务上的能效通常优于可重构架构但RPU赢得了灵活性。对比一款众核处理器性能相近但能效是其两倍。低功耗版本 (REMUS_LPP 75MHz)H.264 BP720p稳定35 fps功耗仅24.5mW。对比ADRES可重构处理器功耗降低76%能效提升3.8倍。对比一款DSP芯片解码速度快16%能效优势巨大。这些数据充分验证了RPU架构在能效上的显著优势。其高性能并非来自疯狂的频率提升而是源于架构创新LSMC, HCC与领域定制化设计异构PE层次化存储的协同作用。4.3 灵活性验证超越视频解码为了证明RPU并非视频专用加速器我们将其应用于更广泛的领域通用计算内核选取了涵盖计算密集如GEMM矩阵乘、SPMV稀疏矩阵乘、FFT、控制密集如Floyd-Warshall、带宽受限如BFS广度优先搜索等类型的13个经典算法内核进行测试。与Intel Atom 230和ARM Cortex-A8处理器对比在计算密集型内核上RPU获得了数倍到数十倍的加速在控制密集型内核上凭借HCC减少配置开销也能获得可接受的性能。而整个REMUS_HPP在运行这些内核时功耗约100mW远低于Atom的4W和Cortex-A8的300mW。数据加密实现了AES和DES算法。通过将算法核心轮函数展开并流水线化映射到PE阵列实现了高吞吐率。与当时先进的众核处理器和FPGA方案相比RPU在达到相近吞吐率的同时能效高出1-2个数量级。GPS基带处理将捕获Acquisition和相关性计算Correlation等计算密集型任务映射到RPU跟踪环路和定位解算由主控处理器完成。最终芯片可同时捕获跟踪9颗卫星功耗仅23.75mW定位精度1.24米完全满足便携设备需求。这些实验表明RPU的架构对于一类具有规则数据流、可并行化、计算密集特征的算法具有普适的高能效加速能力。5. 常见问题与设计反思在实际流片和测试过程中我们也遇到并解决了一系列问题这里分享一些核心的经验和思考。问题一如何确定PE阵列的最佳规模是不是PE越多越好绝对不是。PE数量增加会线性增加面积、功耗和布线复杂度。我们的方法是以应用需求为锚点。通过周期精确仿真找到满足目标性能如1080p30fps的最小阵列规模。仿真时要考虑最坏情况如高速运动场景并留有一定余量。此外异构化是控制面积的有效手段。分析目标应用的算子频率分布对低频但面积大的算子如乘法器进行资源复用。问题二LSMC互连会不会成为数据交换的瓶颈这取决于应用的数据访问模式。我们通过分析视频解码的典型数据流发现其具有强烈的空间局部性。LSMC的“线交换”机制恰好匹配了这种按行/列访问数据块的特征。对于需要完全随机访问所有PE的应用LSMC可能不是最优选择。因此互连网络的设计必须与目标领域耦合。通用、全连接的互连固然灵活但代价巨大。我们的经验是牺牲一点通用性换取面积和能效的巨大收益在嵌入式领域是值得的。问题三HCC方案是否增加了编程和编译的复杂性确实增加了一层抽象。程序员或编译器需要将算法识别并组织成“核心上下文-组上下文-完整上下文”的层次。但这部分工作可以通过自动化工具链完成。我们开发的编译器前端和PolyMAP工具能够自动进行循环变换、内核识别和上下文生成。对于程序员来说他们仍然主要编写标准的C代码只是需要添加一些编译指导语句如#pragma来标识可并行循环。工具链的成熟度是可重构计算能否落地的关键。问题四在真实系统中RPU与主处理器如何高效协同这是一个系统级问题。在我们的SoC设计中RPU作为协处理器通过高带宽、低延迟的接口如AXI总线与主控CPU和共享内存相连。关键点在于任务划分清晰将规则并行部分MC, IDCT, Deblocking卸载给RPU不规则控制部分熵解码、码流解析、帧管理留给CPU。数据搬运优化利用DMA在RPU的本地缓冲如EM和系统主存之间搬运数据与RPU计算重叠进行。配置预取与缓存利用HCC的层次性主机可以提前将组上下文和核心上下文加载到RPU的GGCM/GCCM中运行时只需发送轻量级的完整上下文指令流极大减少了实时配置延迟。问题五这套架构对未来更复杂的编解码标准如HEVC/VVC是否依然有效从计算模式上看HEVC虽然计算量激增但其核心算法运动补偿、帧内预测、变换量化的本质仍是块级的规则并行计算与H.264一脉相承。因此RPU的PE阵列和互连结构仍然适用。挑战可能在于更大的配置上下文HEVC的预测单元和变换单元尺寸更多样可能导致配置模式增加。这可以通过扩展HCC的组上下文层次或增加核心上下文存储容量来解决。更高的数据带宽需求HEVC支持更大的预测块和更多的参考帧需要更大的片上缓冲和更高的内存带宽。这可以通过优化存储层次如增大RIM、EM容量和使用更宽的内存接口来应对。更复杂的控制虽然计算主体仍适合RPU但控制逻辑的复杂度增加需要主控CPU承担更多调度工作。总的来说RPU的架构理念——针对领域特征设计异构可重构计算单元并通过创新的互连和配置管理来最大化能效——具有很好的前瞻性和可扩展性。它不仅成功应用于多标准视频解码也为其他计算密集型嵌入式应用如视觉处理、无线通信基带提供了一种高能效的硬件加速方案。最终的芯片数据告诉我们在追求极致能效的路上精妙的架构设计远比单纯依靠先进工艺更有潜力。
粗粒度可重构处理器架构设计：面向视频解码的高能效计算
1. 项目概述为什么我们需要粗粒度可重构处理器在嵌入式系统和移动计算领域我们一直在性能、功耗和灵活性之间走钢丝。传统的路子无非两条要么用专用集成电路ASIC性能强、功耗低但一颗芯片只能干一件事流片成本高算法一升级就可能过时要么用通用处理器GPP或数字信号处理器DSP编程灵活但面对视频解码这类计算密集、数据并行的任务往往力不从心为了达到实时性能不得不拉高主频功耗就上去了。这时候可重构计算Reconfigurable Computing就成了一条有吸引力的中间路径。它的核心思想是硬件不再是“死”的而是可以在运行时根据软件任务的需求动态改变自身的结构和功能。你可以把它想象成一个乐高积木搭建的计算平台基本的处理单元PE和连接它们的线路互连网络都是可编程的。当需要做运动补偿MC时我就把积木搭成一个并行度很高的矩阵乘法器下一秒需要做反离散余弦变换IDCT了我又可以快速把积木重新排列成一个适合蝶形运算的结构。粗粒度可重构阵列CGRA是这个领域的主流。与FPGA那种比特级细粒度的可编程不同CGRA的处理单元通常是16位或32位的算术逻辑单元ALU粒度更粗。这意味着它的配置信息量更小配置速度更快更适合应对视频解码这种需要频繁在不同计算内核间切换的场景。然而早期的CGRA设计往往过于追求峰值性能忽视了配置开销带来的巨大能量损耗。你想想一个包含上百个PE的大阵列每切换一次任务就要重新灌入成千上万的配置比特这个过程中数据搬移和寄存器翻转消耗的能量有时甚至能赶上计算本身。这成了制约CGRA在能量敏感的移动设备上广泛应用的一个关键瓶颈。我们团队当时接到的任务就是设计一个面向多标准视频解码的粗粒度可重构处理单元RPU核心目标就俩字能效。不仅要跑得快更要在有限的功耗预算下跑得久。最终流片的芯片一个高性能版本REMUS_HPP在200MHz下能解码1080p30fps的H.264视频功耗仅280mW另一个低功耗版本REMUS_LPP在75MHz下实现同样帧率功耗更是低至24.5mW。这背后是一系列从架构到电路级别的协同设计而不仅仅是工艺进步的功劳。1.1 核心需求解析视频解码的计算特征与挑战要设计一个高效的加速器首先得把负载吃透。视频解码流程虽然标准各异H.264, MPEG-2, AVS等但核心步骤大同小异熵解码、反量化IQ、反变换IDCT、运动补偿MC/帧内预测、重建、去块滤波Deblocking。我们对一个典型的H.264解码任务在通用处理器上做了剖析发现超过75%的计算量都集中在MC、Deblocking和IDCT/IQ这几个模块。它们有一个共同特点面向块Block或宏块Macroblock的规则数据并行计算。以运动补偿为例为了预测当前块需要从参考帧中取出一个或多个候选块进行加权求和。这个操作本质上是对内存中一片连续的图像数据做大量的乘加运算SAD, SATD等数据依赖关系简单非常适合在PE阵列上展开并行。去块滤波虽然逻辑稍复杂涉及边界判断和滤波强度选择但其核心操作仍然是针对像素行/列的加减、比较和饱和运算具有很高的数据局部性和并行潜力。这就为我们指明了设计方向RPU的架构必须高效支持这种规则的数据并行、以乘加为核心的算术运算、以及频繁的局部数据交换。同时视频解码是流水线作业不同模块如MC和Deblocking理论上可以并行执行以提升吞吐率。因此架构还需要具备一定的任务级并行能力。另一个容易被忽视但至关重要的挑战是配置效率。视频解码过程中算法内核切换频繁。例如处理完一个宏块的MC紧接着就要处理其IDCT然后可能是Deblocking。如果每次切换都需要数百甚至上千个周期来重新配置整个PE阵列那么宝贵的计算资源将大量时间浪费在“等待”上有效吞吐率大打折扣能效比自然难看。因此如何减少配置信息量、加速配置过程成为提升整体能效的关键。2. 架构核心设计如何打造一个高能效的RPU基于上述分析我们提出了RPU的整体架构。它不是一个孤立的计算阵列而是一个包含完整数据通路和配置通路的协处理器。其核心思想是将计算密集部分卸载到可重构阵列上而控制密集、不规则的部分如熵解码、码流解析仍由主控处理器如ARM处理。RPU的架构框图清晰地划分了这两条路径。2.1 数据通路异构PE阵列与创新的互连网络数据通路的核心是一个可重构处理单元阵列PEA。我们并没有采用常见的同构大规模阵列而是基于视频解码的算子特征设计了一个异构阵列。2.1.1 处理单元PE的精细化设计每个PE的核心是一个16位算术逻辑单元ALU支持26种操作包括加、减、逻辑运算、移位、比较、饱和、绝对值等。关键洞察来自于对H.264/MPEG-2/AVS解码代码的静态和动态分析乘法及相关操作如乘加的出现概率总和不到7%。在视频解码中乘法主要用于运动补偿中的像素插值涉及滤波系数以及变换中的少量系数乘法大部分计算是加、减、比较和饱和操作。因此我们做了一个大胆的优化并非所有PE都配备硬件乘法器。在由4个RCAs可重构单元阵列组成的PEA中只有位于第二行的PE集成了16x16定点乘法器。这样整个芯片的乘法器数量从256个减少到32个。你可能担心这会影响性能但由于乘法操作本身占比低且可以通过编译调度将乘法任务集中映射到这些“富资源”PE上实际性能损失微乎其微。但带来的收益是巨大的PE的总面积减少了约80%。在芯片设计里面积就是成本也是静态功耗的主要来源之一。此外PE的配置寄存器设计也考虑了功耗。我们使用5位固定长度的操作码OPCODE。通过分析大量解码任务的配置序列我们优化了OPCODE的编码使得在典型任务切换时配置比特的跳变0-1或1-0概率最小化且分布均匀。这直接降低了配置网络上的动态功耗。2.1.2 线交换网格互连LSMC在灵活性与面积间取得平衡PE之间的互连网络是CGRA面积和延迟的大头。传统的全互连Full Mesh虽然灵活但每个PE都要与所有I/O端口相连随着阵列规模增大连线数量和开关数量呈平方级增长导致布线拥塞、面积膨胀、功耗激增。我们提出了线交换网格互连Line-Switched Mesh Connect, LSMC。其核心思想是化“全连接”为“线连接”。具体来说我们将一个RCA内的8x8 PE组织成8行。在任一时刻只有特定的一行PE通过一个共享的I/O总线与外部256位宽的FIFO二级FIFO直接相连。PE行内的数据交换则通过一个高效的层内网格网络完成。当需要访问不同行的数据时可以通过配置动态切换哪一行PE连接到I/O总线。这样做的好处非常明显大幅减少了长距离、高扇出的全局连线。实际综合评估显示在阵列规模较大时LSMC的互连部分面积相比全互连方案可减少超过50%。有人可能会问这会不会成性能瓶颈我们通过将MC、Deblocking、IDCT等核心内核映射到两种互连结构上进行周期精确仿真发现LSMC带来的性能损失不超过5%。这是因为视频解码的数据访问模式具有很强的空间局部性连续的数据块往往被映射到相邻的PE行上LSMC结构完全能够满足其带宽需求。用面积换来的能效提升是极其划算的。2.1.3 层次化存储结构匹配数据流光有计算单元不够还得喂得饱数据。RPU设计了多级缓冲存储结构来匹配PE阵列的吞吐率二级FIFO每个RCA配有输入和输出二级FIFO深度分别为32和4宽度为256位对应16个16位数据。这用于缓冲从外部内存涌入的突发数据流平滑访存延迟。宏块缓冲区Macro Buffer一个128x16位的单端口内存用于RCA之间的中间结果交换。例如一个RCA处理完IDCT的结果可以暂存于此供另一个RCA进行运动补偿时读取。RCA内部内存RIM一个64x16位的双端口内存用于单个RCA内部不同计算阶段之间的数据暂存减少对外部存储的访问。交换内存EM一个128x16位的双端口内存作为两个RPU核心在双核配置中之间的共享数据交换区采用乒乓缓冲机制实现计算与数据搬运的重叠。这种层次化的存储设计确保了数据在计算单元周围高效流动避免了因等待数据而导致的PE闲置是提升硬件利用率和能效的关键。2.2 配置通路分层配置上下文HCC大幅削减配置开销如果说数据通路是肌肉那么配置通路就是神经。如何快速、低功耗地“告诉”硬件下一步要做什么是CGRA设计的灵魂。传统的CGRA配置模式可以看作“平铺式”每个任务内核Kernel对应一个完整的、独立的配置比特流Context。切换任务时需要将一整个新Context全部加载到PE的配置存储器中。这对于视频解码这种由众多小内核组成的应用来说效率极低。我们提出了分层配置上下文Hierarchical Configuration Context, HCC方案。它将配置信息抽象为三个层次核心上下文Core Context最底层包含PE的ALU操作码、层内互连配置位、数据加载/存储命令。它定义了PE阵列在一个小计算步骤中的具体形态。组上下文Group Context中间层由一系列核心上下文的索引组成。它描述了一个稍大的、数据相关的计算序列。例如一个宏块的运动补偿可能包含多个相似但数据不同的子块补偿操作它们可以使用相同的PE阵列结构核心上下文只是数据不同。组上下文通过重复调用同一个核心上下文的索引避免了重复存储和传输相同的配置信息。完整上下文Complete Context最高层由组上下文的索引和同步命令组成。它由主机处理器动态生成描述了整个任务如一帧的解码流程。HCC的优势在于极高的数据压缩率。对于H.264解码应用采用HCC后需要存储和传输的配置信息总量相比非分层方案减少了76%。这意味着配置缓存可以更小节省面积和静态功耗配置总线上的数据搬运量大幅减少降低动态功耗配置速度也更快。硬件上我们为RPU配备了专用的全局核心上下文内存GCCM和全局组上下文内存GGCM。主机处理器只需要下发轻量级的完整上下文RPU内部的配置解析器会根据索引从GGCM和GCCM中取出实际的配置位流。实测表明采用HCC后配置时间在RPU总执行时间中的占比从传统架构如XPP40的24%以上降低到了4%-13%。这意味着硬件资源有更多时间是在实实在在地做计算能效自然得到显著提升。2.3 阵列规模探索多大的PEA才够用设计初期一个关键问题是PEA到底要做多大不是越大越好面积和功耗会线性增长。我们需要找到满足性能需求的最小规模。我们的性能约束是在200MHz下能实时解码1080p视频每秒30帧每帧8160个宏块。算下来平均处理每个宏块的周期预算约为816个周期。我们以RCA的高度H固定为8匹配最小计算块4x4变化其宽度W从4到32进行周期精确仿真。仿真结果显示去块滤波Deblocking是其中最耗时的子任务。当W8时四个RCA并行工作处理一个宏块的所有子任务Pred, IDCT, DeB的总周期数开始低于816的预算。继续增大W性能提升的边际效应递减而面积开销却线性增加。当W从8增加到32时PEA面积增长超过3倍。因此8x8的RCA四个组成一个PEA被确定为最优解在满足性能目标的同时实现了硬件资源的最经济利用。实操心得架构探索中的权衡在芯片架构定义阶段这种基于周期精确仿真和面积评估的探索至关重要。不能只盯着峰值性能。我们建立了快速的SystemC模型将关键算法内核映射上去跑仿真同时集成面积预估工具。这个过程中要敢于做“非对称”的异构设计如减少乘法器也要善于利用应用的特征如数据局部性来简化互连。LSMC和HCC这两个核心创新都源于对视频解码这一特定领域负载的深刻理解而不是追求通用的、面面俱到的灵活性。在嵌入式领域“够用就好”的设计哲学往往能带来最佳的能效比。3. 从算法到硬件映射流程与编译支持再好的硬件如果没有高效的编程工具链也只是一堆硅沙。为了让算法工程师能利用RPU我们开发了一套基于C语言的编译框架。3.1 编译流程概述整个流程是源到源的前端处理使用修改版的SUIF2和Mach-SUIF工具链对标准C代码进行解析和优化。编译器会识别出其中计算密集的循环嵌套通常是视频解码的内核将其提取为数据流图DFG。剩余的控制密集型代码则被标注并保留为C代码由主控处理器执行。循环变换与映射这是最关键的一步。我们建立了一个基于多面体模型Polyhedral Model的总执行时间TET分析模型。这个模型同时考虑了配置开销、数据通信开销和计算开销。传统的映射工具往往只优化计算忽略了CGRA中巨大的配置成本。我们的工具PolyMAP将循环嵌套的映射问题转化为一个约束优化问题通过启发式算法搜索最优的循环变换如循环分块、展开、交换方案在三种开销间取得最佳平衡。测试表明相比当时先进的EPIMap和PolyCOM方法PolyMAP在PolyBench测试集和H.264内核上平均能带来22%到32%的性能提升。后端处理与代码生成优化后的DFG通过一个改进的、基于模板的子图同构映射方案映射到具体的PE阵列结构上。这个阶段会充分利用HCC的特性识别出重复的计算模式生成共享的核心上下文进一步压缩配置信息量最终生成可供RPU加载执行的配置流。3.2 映射效果以H.264解码内核为例我们将H.264解码中最关键的三个内核——IDCT、运动补偿MC和去块滤波Deblocking——映射到RPU上并与商业可重构处理器XPP40进行对。算法内核性能指标XPP40 (最坏情况)RPU (典型情况)RPU (最坏情况)IDCT周期/宏块12085102MC周期/宏块180132158Deblocking周期/宏块480305366从上表可以看出RPU在各个内核上的性能均优于XPP40。这得益于更高效的PE架构、LSMC互连带来的高数据带宽以及HCC大幅减少的配置时间。特别是在最耗时的Deblocking滤波上RPU的优化最为明显。注意事项映射的局限性我们的编译器和架构并非万能。对于控制密集型、含有大量不规则分支和回溯的算法如N皇后问题其数据流图难以高效映射到规则的PE阵列上强行映射会导致配置频繁切换和存储开销激增性能甚至可能不如通用处理器。RPU的强项在于规则数据并行和流式处理。因此在系统划分时必须由工程师或高级编译器判断将合适的任务卸载到RPU其余部分留在主控CPU。4. 芯片实现、测试与全面评估设计最终要落在硅上。我们采用TSMC 65nm LP工艺实现了三款芯片来验证RPU。4.1 芯片系列与系统集成CHAMELEON这是一个纯RPU核心的原型验证芯片用于大量算法映射和性能 profiling。RHINOCEROS (SoC)这是一个面向高性能应用的系统级芯片。它集成了两个RPU核心构成REMUS_HPP处理器、一个RPU微控制器RMC、一个主控微控制器MMC、DMA、视频预处理单元VPP负责熵解码等比特级操作以及丰富的外设。双RPU设计允许并行处理MC和Deblocking进一步提升吞吐率。REINDEER (SoC)这是一个面向低功耗便携设备的SoC。它集成了单RPU核心REMUS_LPP处理器和必要的外设主打高能效。4.2 性能与能效评估视频解码我们在真实芯片上测试了多标准视频解码性能高性能版本 (REMUS_HPP 200MHz)H.264 HP1080p稳定30 fps功耗280mW。对比XPP-III性能提升25%能效MB/s/mW提升高达14倍。对比一款专用多格式视频编解码ASIC解码性能相当但能效约为其一半。这符合预期ASIC在专用任务上的能效通常优于可重构架构但RPU赢得了灵活性。对比一款众核处理器性能相近但能效是其两倍。低功耗版本 (REMUS_LPP 75MHz)H.264 BP720p稳定35 fps功耗仅24.5mW。对比ADRES可重构处理器功耗降低76%能效提升3.8倍。对比一款DSP芯片解码速度快16%能效优势巨大。这些数据充分验证了RPU架构在能效上的显著优势。其高性能并非来自疯狂的频率提升而是源于架构创新LSMC, HCC与领域定制化设计异构PE层次化存储的协同作用。4.3 灵活性验证超越视频解码为了证明RPU并非视频专用加速器我们将其应用于更广泛的领域通用计算内核选取了涵盖计算密集如GEMM矩阵乘、SPMV稀疏矩阵乘、FFT、控制密集如Floyd-Warshall、带宽受限如BFS广度优先搜索等类型的13个经典算法内核进行测试。与Intel Atom 230和ARM Cortex-A8处理器对比在计算密集型内核上RPU获得了数倍到数十倍的加速在控制密集型内核上凭借HCC减少配置开销也能获得可接受的性能。而整个REMUS_HPP在运行这些内核时功耗约100mW远低于Atom的4W和Cortex-A8的300mW。数据加密实现了AES和DES算法。通过将算法核心轮函数展开并流水线化映射到PE阵列实现了高吞吐率。与当时先进的众核处理器和FPGA方案相比RPU在达到相近吞吐率的同时能效高出1-2个数量级。GPS基带处理将捕获Acquisition和相关性计算Correlation等计算密集型任务映射到RPU跟踪环路和定位解算由主控处理器完成。最终芯片可同时捕获跟踪9颗卫星功耗仅23.75mW定位精度1.24米完全满足便携设备需求。这些实验表明RPU的架构对于一类具有规则数据流、可并行化、计算密集特征的算法具有普适的高能效加速能力。5. 常见问题与设计反思在实际流片和测试过程中我们也遇到并解决了一系列问题这里分享一些核心的经验和思考。问题一如何确定PE阵列的最佳规模是不是PE越多越好绝对不是。PE数量增加会线性增加面积、功耗和布线复杂度。我们的方法是以应用需求为锚点。通过周期精确仿真找到满足目标性能如1080p30fps的最小阵列规模。仿真时要考虑最坏情况如高速运动场景并留有一定余量。此外异构化是控制面积的有效手段。分析目标应用的算子频率分布对低频但面积大的算子如乘法器进行资源复用。问题二LSMC互连会不会成为数据交换的瓶颈这取决于应用的数据访问模式。我们通过分析视频解码的典型数据流发现其具有强烈的空间局部性。LSMC的“线交换”机制恰好匹配了这种按行/列访问数据块的特征。对于需要完全随机访问所有PE的应用LSMC可能不是最优选择。因此互连网络的设计必须与目标领域耦合。通用、全连接的互连固然灵活但代价巨大。我们的经验是牺牲一点通用性换取面积和能效的巨大收益在嵌入式领域是值得的。问题三HCC方案是否增加了编程和编译的复杂性确实增加了一层抽象。程序员或编译器需要将算法识别并组织成“核心上下文-组上下文-完整上下文”的层次。但这部分工作可以通过自动化工具链完成。我们开发的编译器前端和PolyMAP工具能够自动进行循环变换、内核识别和上下文生成。对于程序员来说他们仍然主要编写标准的C代码只是需要添加一些编译指导语句如#pragma来标识可并行循环。工具链的成熟度是可重构计算能否落地的关键。问题四在真实系统中RPU与主处理器如何高效协同这是一个系统级问题。在我们的SoC设计中RPU作为协处理器通过高带宽、低延迟的接口如AXI总线与主控CPU和共享内存相连。关键点在于任务划分清晰将规则并行部分MC, IDCT, Deblocking卸载给RPU不规则控制部分熵解码、码流解析、帧管理留给CPU。数据搬运优化利用DMA在RPU的本地缓冲如EM和系统主存之间搬运数据与RPU计算重叠进行。配置预取与缓存利用HCC的层次性主机可以提前将组上下文和核心上下文加载到RPU的GGCM/GCCM中运行时只需发送轻量级的完整上下文指令流极大减少了实时配置延迟。问题五这套架构对未来更复杂的编解码标准如HEVC/VVC是否依然有效从计算模式上看HEVC虽然计算量激增但其核心算法运动补偿、帧内预测、变换量化的本质仍是块级的规则并行计算与H.264一脉相承。因此RPU的PE阵列和互连结构仍然适用。挑战可能在于更大的配置上下文HEVC的预测单元和变换单元尺寸更多样可能导致配置模式增加。这可以通过扩展HCC的组上下文层次或增加核心上下文存储容量来解决。更高的数据带宽需求HEVC支持更大的预测块和更多的参考帧需要更大的片上缓冲和更高的内存带宽。这可以通过优化存储层次如增大RIM、EM容量和使用更宽的内存接口来应对。更复杂的控制虽然计算主体仍适合RPU但控制逻辑的复杂度增加需要主控CPU承担更多调度工作。总的来说RPU的架构理念——针对领域特征设计异构可重构计算单元并通过创新的互连和配置管理来最大化能效——具有很好的前瞻性和可扩展性。它不仅成功应用于多标准视频解码也为其他计算密集型嵌入式应用如视觉处理、无线通信基带提供了一种高能效的硬件加速方案。最终的芯片数据告诉我们在追求极致能效的路上精妙的架构设计远比单纯依靠先进工艺更有潜力。
