AXI MPU设计实战：片上内存权限检查与RTL实现要点

1. 项目背景为什么片上内存需要一套权限检查机制1.1 多主控访问与SoC内存安全做SoC集成的朋友应该深有体会芯片上最容易被低估的模块往往不是CPU核不是DDR控制器而是那片看起来“人畜无害”的片上内存OCM、TCM、SRAM。它不像DDR那样动辄几百兆的带宽需求也很少出现在架构评审的PPT首页但一旦多个主机同时访问它数据被踩、地址被越界、非法访问被静默丢弃这类问题就会立刻浮出水面。所谓“多主机”在我这个项目里是指CPU应用处理器、DMA控制器、硬件加速器以及调试子系统。这几路AXI主口会同时访问同一块片上SRAM而它们的安全等级、访问意图和数据机密性完全不同。比如CPU需要读指令、写数据DMA要把外部数据搬运进来调试子系统则需要无差别读写任意地址。如果这片SRAM完全裸奔不做任何权限区分那意味着任何一个相对低权限的模块都可以通过发起AXI传输拿到高权限数据。问题的核心在于AXI协议本身只是一套传输握手协议它负责把地址、数据、响应正确地在主从之间搬运但不关心“谁有资格访问这个地址”。权限检查必须由额外的逻辑来施加这正是MPUMemory Protection Unit内存保护单元存在的理由。放在AXI总线和片上内存之间让它对每一笔AXI访问进行地址匹配、属性判定、授权拦截是这类设计的典型做法。这个项目正是围绕这个需求启动的给项目里的80KB片上SRAM加一道AXI MPU的权限检查。目标很明确——让系统里的每个主控按照预设的权限表访问内存越权访问直接以错误响应拒绝而不是把坏数据写进SRAM或者让读回的数据泄露出安全边界。1.2 AXI MPU在三类场景中的价值在动手写RTL之前我得先把场景想清楚否则权限规则容易设计得过于复杂或者过于宽松。这个MPU设计重点覆盖了三类典型场景。第一类是安全隔离。产品需要支持从多个外部接口接收数据其中部分数据属于关键代码段会被CPU取指执行。这类数据所在的内存区域应当禁止DMA写入或调试子系统改写。现实中很多嵌入式产品出现代码被覆盖导致跑飞的问题追究下来往往就是DMA写穿了代码段。加上MPU之后非授权的写请求直接打回物理上不允许它发生。第二类是访问错误定位。很多SoC在调试阶段会遇到“数据莫名变化”的灵异问题RTL仿真明明正常上板之后某个变量的值会偶发丢失。这类问题很多源于非法访问被双方错误握手掩盖了或某路主控在FIFO半满时发出的突发写跨越了内存边界。MPU在这里可以作为一个透明的监控哨点既要做硬性拦截也要记录访问者的ID、地址、属性让现场问题可以回溯。第三类是系统层面的访问分级。同一块SRAM有不同的物理地址段有的段只对特权软件开放有的段连指令预取也不允许。通过MPU的判断逻辑不同主控、不同传输类型都能映射到对应的权限轨迹上。只要想清楚这三类场景MPU的寄存器接口、状态输出、错误记录结构基本就能定下来了。方案上不需要追求大而全够用、可控、可诊断才是这个模块的核心价值。2. AI辅助下的方案设计与架构选型2.1 为什么选择AI辅助做RTL开发我在这几年接触AI辅助硬件开发的体会是它当不了架构师但绝对是个称职的“高级编码员”。在这个项目里AI承担的更多是结构性代码生成、参数计算、验证脚本搭建以及SystemVerilog断言等偏模板化的工作。举个例子AXI MPU里的核心逻辑其实是“地址匹配属性判定事务拦截”。这套逻辑一旦把接口定义清楚RTL代码本身的算法复杂度并不高但是工作量很琐碎每个通道读写地址通道、读数据通道、写响应通道都要做状态判断突发存储体burst length要参与地址边界计算非对齐传输要特别处理最重要的是多主控不同的ID需要映射到不同的权限组。这类代码如果把所有细节都手写很容易陷入“复制、改参数、再复制”的重复劳动。用AI生成初版代码再人工逐行审查修改效率上能提升不少。我实际上用的是基于大模型的内网辅助编码工具不对具体品牌做背书但核心体验是给它喂一段结构清晰的接口定义和权限需求描述它能一次性生成基本可编译的SystemVerilog文件。当然它生成的代码正确性不能直接信尤其是组合逻辑里那种隐蔽的锁存器、复位边界的毛刺、多时钟域潜在的亚稳态问题必须靠人工评审和仿真把住最后一道关。这正是AI辅助硬件研发的正确姿势AI负责把80%的规范代码铺开工程师负责那20%的决定性判断。比如权限优先级如何裁决、非法访问后错误响应到底走DECERR还是SLVERR、全局使能开关和复位策略如何设计这些还是得人来定。2.2 AXI MPU整体架构拆解项目里这片SRAM连接在AXI交换矩阵的一个从端口上。MPU的位置有两种选择一种是把MPU做成独立模块插在主控和SRAM控制器之间另一种是把MPU逻辑直接集成到SRAM控制器前端做一个wrapper。我选择的是后者做一个AXI4三通道AW、W、AR协同的MPU外围逻辑挂到现有的SRAM控制器前面。这样设计的好处在于一是改动范围可控SRAM控制器本身保持原样MPU判断不通过时不产生任何SRAM操作二是对系统中其他模块透明上游的AXI互联不需要做任何修改所有主控最终只会看到MPU暴露出来的从口行为符合AXI协议规范。整体架构可以拆成四个子块地址过滤与区域匹配单元、权限属性判定单元、错误响应生成单元、配置寄存器组。地址过滤单元对外来访问的AXI地址和突发边界做拆解判断本次传输覆盖的所有地址是否都落在允许区间权限属性判定单元根据当前请求的主ID、访问属性prot字段、区域命中结果给出授权判决错误响应单元负责在不通过时生成合规的错误响应避免总线悬挂配置寄存器组则提供一个APB或AXI-Lite配置口软件可以在运行中动态切换区域的权限属性。功能划分清楚之后时序上要特别注意一点MPU的判断逻辑必须插入在不影响关键路径的位置。SRAM读数据通常是要吃紧时序的如果MPU的地址比较逻辑串在地址通道中就可能让原本能跑到800MHz的接口直接降频。我的处理办法是让区域匹配逻辑并行于SRAM地址解码权限判定只在命中结果上做选择尽量不额外拉长组合路径。这样在时序结果上多付出的只是一级与或门的代价。3. 权限检查的核心实现细节与实操要点3.1 AXI总线上的关键信号与prot位做AXI MPU绕不开的是对AXI通道信号的理解。很多刚入手AXI的工程师容易盯着数据通道看但对权限检查而言真正关键的是AWPROT和ARPROT这两个3位信号以及AWID/ARID这几个标识符。PROT[2:0]各bit的含义在AXI3/AXI4规范里有明确解释bit[0]是安全属性0表示非安全传输1表示安全传输bit[1]表示传输类型0是数据访问1是指令访问bit[2]表示特权级别0表示普通访问1表示特权访问。这三位的组合就可以做出一个基础的访问属性模型。实际项目里CPU发出的取指请求往往体现为指令访问结合安全属性和特权位就可以定义一组规则代码段只允许特权安全的取指请求访问DMA的数据写入永远不被放行到代码段。这样即使DMA的地址计算出错想要把数据写到代码区域在MPU这一层就直接被挡住了。这是一条非常实用且容易让验证人员理解的规则。另外还有一个非常重要的信息点响应信号里的BRESP和RRESP也不只是OKAY一种取值。当MPU拒绝一笔传输时可以返回DECERR地址解码错误或者SLVERR从设备错误。这两者语义上的差别在于DECERR更偏向“这个地址对我而言根本不存在”SLVERR更偏向“地址存在但我拒绝或者处理失败了”。从使用方软件的角度区别不大都是从驱动里收到错误码。但从系统诊断的角度DECERR会让调试者认为访问地址非法而SLVERR会让人先怀疑硬件模块状态不对。我的建议是MPU拦截越权访问时统一返回SLVERR同时在MPU内部记录错误原因寄存器这样软件能在收到SLVERR后通过读寄存器快速定位具体是因为哪个属性不满足被拦截的。这在实际调板阶段节省了大量时间。3.2 区域配置基地址、掩码与优先级区域匹配逻辑是MPU最基础的部分。片上内存空间通常会划分成多个区间比如4KB的启动代码段、8KB的密钥数据段、32KB的可读写数据段、剩余部分为非缓存数据段。每个区域需要配置的寄存器包括基地址、地址掩码、区域使能、读写允许位、安全属性允许位、特权等级允许位等。地址掩码的设计上我建议采用“基地址 掩码”而不是“基地址 上限地址”。原因很实际在硬件上做“低于上限”比较需要两级比较器而掩码匹配只需要对地址和目标基地址做与运算再比较组合逻辑短、实现简单。例如一个区域基地址是0x00080000掩码是0x000FFFFF那对地址做addr mask后等于0x00080000的就是这个区域内。区域大小为2的幂次方时这种写法最自然。区域重叠是必须考虑的问题。多个区域的基地址可能因为配置错误而重叠此时需要一个明确的优先级规则。我的做法是给每个区域配一个4位的优先级段数字大者优先。当一次访问命中多个区域时以优先级最高的区域权限属性作为判定结果。这个规则要写进寄存器描述文档里验证用例也要专门覆盖。如果区域数量不大我这边只有8个区域还可以用“第一个命中的区域”这种顺序仲裁实现更简单不容易在优先级上绕晕。8个区域用优先级段有点杀鸡用牛刀但考虑到后续可能有客户需要通过寄存器动态调整区域角色独立优先级提供了更大的灵活性保留下来也不亏。还有一个容易漏掉的细节AXI传输是突发式的一次写突发可能跨越区域边界比如一个长度为8的突发从区域1的尾部发起中间会穿入区域2。MPU在做区域判定时不能只看首地址要结合AXI的突发长度和字节通道计算传输覆盖的地址范围保证范围内所有地址都具备合法权限否则就拒绝整个突发。这种边界情况如果不做会出现前半段写成功了、后半段丢失的“半成功”场景对软件极不友好。这个迎头问题必须从设计初始就纳入规则。3.3 RTL实现要点与通过AI填坑RTL层核心逻辑可以写成一套组合判定我贴一段简化思路的SystemVerilog作为参考always_comb begin region_hit 0; for (int i 0; i NUM_REGIONS; i) begin if (addr_reg_cfg[i].ena ((awaddr region_cfg[i].addr_mask) (region_cfg[i].addr_base region_cfg[i].addr_mask))) region_hit[i] 1b1; end end这一段的意图是并行比较所有配置区域任何一个区域命中就置位对应的hit信号。需要注意的是这个for循环可以被综合工具展开成并行逻辑但一定要确保addr_mask在配置时被正确初始化否则上电默认值为0会导致所有地址都命中0基地址区域潜在风险非常大。AI在这个阶段最能发挥价值的地方是帮我把每个通道的握手逻辑和错误响应状态机搭出来。AXI从口拒绝一笔传输有讲究AW通道的请求如果被拒绝按理说可以立刻生成B通道的SLVERR但要确保W通道的数据已经被接收或直接丢弃且不能让总线hang住。AR通道的拒绝相对简单直接在R通道返回错误响应即可不需要读取SRAM数据。AI生成的初版状态机里反复出现的一个问题是在拒绝AW传输的时候会把W通道的数据也“吃掉”但由于W和AW是两个独立的通道时序上WLAST可能还没到必须等W通道数据完整接收后再发出B响应。这个坑靠仿真抓了很久才定位清楚后来让AI针对该点重写状态机再人工加注释锁定逻辑才算彻底解决。另一个值得说的是锁存器和复位。AI生成的代码很喜欢用不带else的组合always块这在综合时容易产生锁存器时序收敛阶段很麻烦。我的处理方式是在交给AI的提示词里就明确要求“组合逻辑必须完整赋值”“禁止锁存器风格”生成后再用lint工具扫描确保没有latch的warning。实测AI生成的代码经过两三轮修正后lint基本能一次过但前提是提示词写得足够细。4. 验证与调试实录怎么证明它是对的4.1 基于UVM的定向验证MPU这类安全模块的验证不能只依赖随机测试必须走“UVM环境 定向用例 异常注入”的组合路线。项目里我搭了一个比较轻量的UVM环境大致包含一个AXI主代理、一个SRAM从代理、一个MPU寄存器模型以及几个用于注入非法访问的sequence。验证环境的架构部分AI帮了不少忙尤其是sequence基类、寄存器前门访问的样板代码基本是提示词加少量修改就能生成的。但验证的核心是确认边界行为这部分的用例需要人来设计。我列了一批必测的定向场景每个区域的起始地址和结束地址边界访问突发传输跨越区域边界时整个突发的拒绝非法写请求触发B通道SLVERR同时确认SRAM侧没有真正的写脉冲非安全属性和普通权限等级访问安全区时的拒绝多个区域重叠时优先级裁决是否符合预期配置寄存器关闭某个区域后该区域的访问立即被拒绝。其中最有价值的一个用例是“写拒绝但读允许”的场景。如果配置某个区域只读不可写非法写请求必须被MPU拦截但同一地址的读请求必须正常返回SRAM数据。这看起来是一个简单规则但实现上却需要把AW、W通道的判定和AR通道的判定分开处理而很多初版实现容易把它们搅在一起导致非法写被拦截后合法读也受影响。这个用例在整个联调过程中成功抓出了三轮时序问题属于必须放在回归集里的重量级用例。4.2 断言与形式化检查除了功能仿真我在这个模块里加了不少SystemVerilog断言SVA用一句话概括就是把“不能发生的事情”显式写出来让仿真器自动帮我们盯住。比如断言“没有授权的写请求绝不允许置起SRAM的写使能”写成SVA就是property no_unauth_write; (posedge clk) disable iff (!rst_n) if (req_valid ar_hit_flag !region_write_grant) not (sram_wen); endproperty类似的断言还包括MPU返回SLVERR时必须同时拉高错误响应有效信号且不能在同一个时钟周期还会继续置起SRAM的写使能当拒绝写突发时必须等到WLAST之后才发出BVALID区域命中信号在任何时刻最多只有一个有效输出。这些断言在回归仿真里做实时监控跑上千个随机用例后有粗疏问题会直接fail比靠肉眼盯波形可靠得多。形式化验证可以做但对于一个中等复杂度的MPU受限于工具运行时间和开发节奏我做的是轻量级的formal check集中在地址比较器和状态机可达性分析上没有做整套属性证明。这类安全模块如果量产出货最好还是补一轮正式化验证把“非法访问必被拦截”这条性质证明完整。4.3 真实踩坑与排查记录调试阶段踩过最坑的一次问题是仿真的RTL行为看起来完全正确——非法访问确实返回了SLVERRSRAM侧的数据也确实没有被改。但上板验证时软件通过AXI-Lite配置完MPU寄存器后合法读操作却偶发返回错误数据。查了很久才意识到配置寄存器本身是异步接口软件写入MPU寄存器时组合路径上用了未打拍的寄存值去锁存新的配置导致同一时刻出现半旧半新的配置状态逻辑上把当时合法的地址也判成了非法。解决方法是所有配置寄存器在写入后先同步到AXI时钟域再做组合判定。同步过程会增加一到两个周期的配置生效延迟在启动流程里完全可接受。这里也提醒了我MPU作为控制面模块对配置寄存器的同步要求不能比业务数据通道低。另一个值得记录的坑是复位阶段。软件在初始化阶段还没有配置好任何区域时MPU默认行为应该是什么样的如果所有区域关闭且默认拒绝一切那CPU自己取指都会被挡住系统直接进不了启动流程。我的处理是增加一个hardware default规则在系统复位释放到MPU配置完成之前内部一个“default_access”信号保持为允许状态并且只允许特权安全访问经过其他请求全部拒绝。这样启动代码本身运行在特权模式可以执行而普通外设访问在启动早期就被隔离在外。这个逻辑虽然不复杂但容易在验证时被忽略直到集成测试阶段才暴露所以务必作为验证用例前置。5. 集成落地的经验与扩展建议5.1 在SoC中挂接与时序收敛MPU实现完成、模块级验证通过之后真正的麻烦刚开始把它挂到SoC里。集成时首先要确认的是AXI端口对齐。我的MPU是作为一个AXI4从模块挂在交换矩阵上的所以需要把AW、W、B、AR、R五个通道的信号全部按协议完整暴露出来任何通道上缺少一个handshake信号互联矩阵的对齐检查都会报错。这里常见问题在于ID信号的处理。AXI互联赛一般要求从设备必须响应与请求相同的ID但MPU内部如果不对ID做重排那就直接把ID信号透传回去。透传会导致一个问题多个主控共用同一ID访问MPU时错误日志寄存器可能无法区分具体发起者。我的做法是在MPU内部增加一个可选的ID日志寄存器把发起非法访问的AWID或ARID锁存下来同时保留对外ID透传。这样软件通过日志就能定位到具体是哪个主控的行为触发了拦截排查效率高了很多。时序收敛上关键路径主要出现在两部分区域匹配组合逻辑和错误响应状态机的仲裁逻辑。区域匹配作为组合逻辑连接到各主控过来的地址总线如果地址总线本身就是长走线叠加在MPU内部的多个比较器上就可能形成setup违例。我的优化手段是把区域比较器拆成两级第一级先做基地址与掩码的与运算第二级再做相等比较或者也可以在一个时钟周期内先将地址打拍下一个周期再给出判定结果代价是多一个流水周期。对于RAM访问这类本身需要一拍地址译码的从口多出的一拍几乎不影响性能。5.2 后续扩展Secure MPU、QoS、调试对策如果项目周期允许我觉得还可以在这个AXI MPU基础上做三个方向的扩展。第一个方向是控制面增强把现在的0到7号区域扩展到更多的区域项并增加per-ID权限表。目前的设计只支持通过输入端口预先给每个主控分配一个ID权限组权限组再映射到区域属性。扩展后就可以让每个ID有独立的读、写、安全、特权允许位粒度更细。代价是寄存器数目上升配置复杂度和软件驱动工作量都会增加所以需要在系统层面评估这个投入划不划算。第二个方向是增加QoS支援。如果软件在做实时视频通路时发现排在繁忙队列里的SRAM访问被卡住可以在MPU里增加一个紧急访问通道优先放行带QoS高优先级属性的请求。第三个方向是调试对策。MPU不能只做“挡”的动作还应该有“录”的能力。当前设计里有错误日志寄存器后续建议增加一个小型追踪FIFO记录最近N次被拦截传输的完整上下文包括ID、地址、字节通道、prot属性、发生时刻。这样发生问题后软件可以直接读出一个“最近违规列表”不用靠逻辑分析仪去抓瞬时信号。尤其在量产设备只能通过远程日志排查问题时这个功能的价值会被放大。把这篇实践写下来我的初衷是提醒大家片上内存并不是一眼望到底的简单存储阵列在多主控SoC里它同样需要明确的访问边界和审计能力。AI辅助开发这部分我想强调的是它加快了代码铺开的速度但无法替代对AXI协议细节的掌握和验证覆盖的完整度把专业判断留给自己把重复编码交给工具这个配合方式才是我认为最舒服、也最不容易翻车的状态。