拓冰网站定制 
前阵子干了个挺磨人的活儿给片上SRAM前面加了一道 AXI MPUMemory Protection Unit也就是给片上内存加一道权限检查。整个过程还拉上AI大模型当了一把“外援工程师”从RTL设计、UVM验证到波形调试都掺和了一遍。做下来最大的感受是MPU本身的逻辑不复杂但把它塞进SoC总线矩阵里要和AXI协议、仲裁器、DMA、CPU这些角色咬合好坑全藏在细节里。这个项目适合谁参考呢做SoC集成、IC前端设计、FPGA原型验证的同学尤其是准备在自己设计里加安全隔离、权限控制又不太想从零手写总线检查逻辑的这篇应该能帮上忙。我会把MPU的设计思路、AXI通道上的检查点、违例处理策略、AI辅助开发的实操方法以及验证时踩过的几个坑都摊开来讲。1. 为什么非得在内存前面加一道门1.1 多主共享片上内存的混乱现场先还原一下项目里的真实场景。一颗小规模的SoC里CPU、DMA0、DMA1 三个主设备都要访问同一块片上SRAM。最初的做法很简单挂一个带优先级仲裁的 AXI 仲裁器谁发请求谁就能读能写仲裁器只管分时复用总线根本不看请求合不合法。问题很快就暴露了。DMA在做外设搬运时如果描述符里的源地址或者长度配错了DMA就会朝着片上SRAM的任意地址一顿写。运气好时写的是未使用区域静默覆盖后面查数据对不上才反应过来运气不好直接写到CPU的中断向量表、栈指针所在的地址区域整个系统跑飞。更要命的是两个DMA同时运行如果软件配置不当DMA0完全有可能把DMA1正在使用的数据缓冲区改掉这种问题复现难、排查难因为出事的时候大家第一反应是“软件配置有问题”但硬件上没有任何兜底手段。这个需求其实不是我们拍脑袋想出来的。稍微大一点的SoC安全隔离、多域共享、功能安全场景里MPU几乎是标配。ARM、RISC-V 处理器内核里的MPU管的是内核视角的地址空间访问控制而我们这里的MPU是站在总线层面对发往内存的所有 AXI 事务做权限检查。二者不是替代关系而是互补处理器MPU管软件bug总线MPU管一切主设备的非法访问包括外设、DMA、调试接口。1.2 AXI请求里其实自带“身份信息”很多人以为权限检查很难做其实AXI协议在请求侧已经给了我们足够的信息关键是你会不会用。以 AXI4 的写通道为例主设备发出写请求时AWADDR带上目标地址AWLEN和AWSIZE决定了这次传输有多少拍、每拍多少字节AWID用于标识这是哪个master或哪条outstanding事务AWPROT则携带了安全/特权/数据指令属性。这些信号组合起来其实就是一份完整的“访问意图说明书”谁AWID、要去哪AWADDR、要干嘛读写由AW/AR通道区分、带宽多大LEN*SIZE、以什么权限访问AWPROT。MPU要做的就是用这份“说明书”去对照一组预先配置好的规则。规则描述的是某个地址区域允许哪些主设备访问、允许读还是写、是否要求Secure属性、是否允许非特权访问。匹配通过就放行不匹配就拦下来同时回一个错误响应告诉发起方“你的访问被拒了”。顺着这个思路MPU可以被拆成三件套地址区域匹配、权限校验、违例响应生成。后面每一块我都会展开讲。2. 权限检查逻辑到底怎么设计2.1 地址区域匹配mask 还是 basesize在动手写RTL之前先解决一个基础问题区域配置寄存器用掩码mask方式还是基地址大小basesize方式。掩码方式的规则是(addr ^ base) ~mask 0也就是地址与基地址逐位异或后被掩码覆盖的位必须全为0。它的好处是只用一个比较器加上一些逻辑门就能完成匹配面积小、路径短非常适合对时序敏感的总线路径。代价是区域大小必须是2的幂次而且对齐要求严格。比如你只想保护一张256字节的配置表如果它恰好不落在自然对齐的256字节边界上mask方式就很难精确表达。basesize方式更直观addr base addr base size。它可以保护任意大小、任意对齐的地址区间但比较器要多做一个加法器和两级比较路径更长。对片上SRAM这种动辄64KB、128KB的内存我通常会选择basesize方式因为实际使用中很难保证每一个需要保护的缓冲区都恰好是2的幂次对齐。如果做的是Cache、TCM这类天然对齐的存储mask方式更省面积。实际项目里我两种都写过最后拍板用basesize理由很实际需求方总是会提出一些“不规整”的保护区间比如“从0x8000_1000开始大小0x2A00”你用mask表示试试要么扩区间保护了不想保护的地址要么拆成多个region。basesize虽然硬件贵一点但软件配置灵活验证也直观。2.2 region匹配的优先级与重叠处理区域配置通常是多组的比如8组或者16组。多组就绕不开一个问题如果一个访问地址同时落在多个区域配置里以谁为准硬件上必须有一个确定的优先级约定否则验证没法写。常规做法是固定编号优先比如region0优先级最高region15最低匹配时从高优先级到低优先级逐个比较一旦命中最高的那个就停止。还有一个惯例未使能的region直接算“未命中”不参与比较。软件使用上还有一个容易忽略的点如果一个低优先级区域是“限制区”比如禁止访问而高优先级区域是“放行区”那么放行区的配置必须把边界收紧不能让禁区的地址被更高优先级的区域“覆盖”后放行。这一点我会在验证章节里专门讲因为随机配置下非常容易踩。2.3 违例响应怎么选SLVERR、静默丢弃还是中断检查不过的请求怎么处理是设计MPU时最容易想当然、也最容易出错的地方。新手第一反应是“拦下来不就行了”但AXI协议有个铁律每个请求必须有且仅有一个响应。你可以在地址通道把请求挡在门外但发起方还在等待响应等不到就会挂死——DMA可能一直在重试CPU可能一直停在总线上。所以MPU必须给违例的请求生成一个“合法”的响应。AXI4 里最合适的违例响应就是 SLVERRslave error0b10。对应的读通道在RRESP上回SLVERRRLAST必须照常置位RLAST的拍数和违例请求的burst长度严格一致写通道则在B通道回SLVERR。这里有个细节写通道处理违例请求时数据仍然可能已经在W通道上传到了MPUMPU不能私下丢弃W通道数据而是要继续接收完整个write data burst照常置WREADY到B通道再回错误。如果中途把WREADY拉低主设备会因为数据发不出去而卡住。响应完之后要不要打断CPU通常要。我们的做法是违例事件发生时除了回SLVERR还拉一个mpu_violation_intr中断给CPU同时把违例的地址、请求ID、读/写方向、命中的region编号锁存到状态寄存器里。中断的作用是让软件能及时感知非法访问而不是等系统功能出错了才回头查。这里还要提一个非常有用的调试模式fail-open。正常工作下MPU命中违例就拦截、报错调试模式下可以配置成“不拦截、只记录违例信息、继续放行”。这个模式对定位软件问题极有价值因为有些违例是因为DMA描述符配错了直接拦截会导致系统状态变化原始现场就丢了。先fail-open抓到脏数据再fail-closed修正能省大量联调时间。3. 核心模块实现RTL细节与AXI通道咬合3.1 模块边界与端口规划MPU插在内存控制器之前还是之后是有讲究的。两种做法我都试过。挂在内存控制器之后MPU只管内存控制器收到的请求好处是挡不住未经内存控制器访问的外设——如果总线上还有别的路径能绕过内存控制器到达SRAM这条路就漏了。挂在仲裁器之前、每个主设备的请求入口处检查最安全但代价是每个入口都要一份检查逻辑面积翻倍。实际工程里最常见的是在仲裁器输出侧、内存控制器入口挂一个集中式MPU。仲裁器已经把多个master的请求汇聚成一个单口事务流MPU在这个点只处理一个通道逻辑简单、面积小。但要留意仲裁器在合并请求流的时候会不会丢掉或者改写PROT、ID信息如果会MPU就查了个寂寞。所以选这个方案时要先确认仲裁器是否透传ARPROT/AWPROT我是踩过这个坑的后面验证章节会细说。端口设计上MPU本质上是个AXI slave口进、AXI slave口出从内存控制器视角看是master侧但对外呈现为一个“可配置的旁路网关”。核心端口如下端口组方向说明s_axi_*输入来自仲裁器的AXI请求含AR/AW的ADDR、ID、PROT、LEN、SIZE等m_axi_*输出送往内存控制器的AXI请求放行时原样透传cfg_*输入配置接口挂CSR总线用来读写各region的基地址、大小、权限位violation_stat输出违例信息锁存包含地址、ID、方向、命中的region编号violation_intr输出违例中断请求1脉冲或电平可选3.2 检查逻辑的SystemVerilog骨架我先把最核心的检查逻辑骨架贴出来。这个版本是给AI辅助生成的初版我后来做了裁剪加上了关键注释module axi_mpu #( parameter int NUM_REGIONS 8, parameter int ADDR_W 32, parameter int ID_W 4 ) ( input logic clk, input logic rst_n, // AXI slave侧来自上游 input logic [ID_W-1:0] s_awid, input logic [ADDR_W-1:0] s_awaddr, input logic [7:0] s_awlen, input logic [2:0] s_awsize, input logic [2:0] s_awprot, input logic s_awvalid, output logic s_awready, // ... W、B、AR、R通道略 output logic violation_intr ); // region配置数组基地址、大小、使能、读写权限、安全属性、master白名单 typedef struct packed { logic en; logic [ADDR_W-1:0] base; logic [ADDR_W-1:0] size; logic read_ok; logic write_ok; logic secure_only; logic [2**ID_W-1:0] master_mask; } region_cfg_t; region_cfg_t cfg [NUM_REGIONS]; // 配置寄存器读写逻辑请自行补全这里不展开 // 1) 区域匹配命中返回region编号未命中返回NUM_REGIONS function automatic int find_hit_region( logic [ADDR_W-1:0] addr ); int hit NUM_REGIONS; for (int i 0; i NUM_REGIONS; i) begin if (cfg[i].en addr cfg[i].base addr cfg[i].base cfg[i].size) begin hit i; break; // 优先级region编号小者优先 end end return hit; endfunction // 2) 权限检查输出是否违例以及命中的region logic aw_violation; logic ar_violation; int aw_hit_region; int ar_hit_region; logic [ADDR_W-1:0] aw_addr; logic [ADDR_W-1:0] ar_addr; assign aw_violation (aw_hit_region NUM_REGIONS) || // 未命中任何区域默认拒绝 (!cfg[aw_hit_region].write_ok) || (cfg[aw_hit_region].secure_only s_awprot[1]) || // non-secure访问被拒 (!cfg[aw_hit_region].master_mask[s_awid]); // 如果burst跨越区域边界还要额外做地址抬升检查 // last_addr aw_addr ((1s_awlen) s_awsize)超出上限同样拒 // ar通道逻辑与aw完全对称不再重复粘贴 // 3) 违例响应生成 // 写违例继续接收W数据到WLASTB通道回SLVERR不向内存发起写 // 读违例R通道回SLVERRRLAST与请求长度对齐DATA读返回常量 endmodule这段骨架看起来简单但真把它填完整会有几个非常折磨人的细节。第一个是burst边界抬升检查。片上内存经常出现这种情况一次INCR类型的burst从区域A内部开始burst长度8每拍4字节地址一路涨涨到最后已经跨出区域A的边界甚至冲进了区域B。如果只查首地址后续拍就漏了。我们的做法是在检查逻辑里算一下“last beat地址”logic [ADDR_W-1:0] aw_burst_bytes; logic [ADDR_W-1:0] aw_last_addr; assign aw_burst_bytes ({8h00, s_awlen} 1b1) s_awsize; assign aw_last_addr s_awaddr aw_burst_bytes - 1;然后这个aw_last_addr也要参与区域匹配。也就是说一次写请求需要同时满足首地址落在合法区域内而且最后一拍地址仍然落在同一个region的合法范围内。这个方法比逐拍检查省逻辑而且完全覆盖了地址单调递增的INCR和FIXED类型。对WRAP类型的burst因为回绕地址一定落在首地址对齐的地址块内只要burst总长不跨越子块边界首地址检查基本能兜住但为了保险我还是会对last_addr做一次检查。第二个是ID过滤的粒度问题。AXI的ID是事务标签不是严格的“主设备编号”。一个master可以在不同时刻发不同ID的outstanding事务甚至软件可以通过不同ID配置不同的QoS。所以MPU的master_mask不能简单按“谁是谁”来配而应该按业务场景来配。比如“所有ID为0、1、2的请求都来自CPU子系统允许全权限”“ID为0xC的请求来自调试接口禁止访问安全区”。这个表是SoC集成时统一规划的配置错了比逻辑错了更难查。第三个是配置寄存器的同步问题。MPU的region配置不是恒定不变的软件运行中会动态调整。如果配置更新发生在有outstanding事务在飞的时刻可能出现一种竞态旧请求在检查阶段读到的还是旧配置新请求已经用了新配置行为不一致很难复现。我们的做法是提供一个cfg_commit寄存器软件先改各region的shadow配置全部就绪后写commit寄存器一次性生效生效前当前拍的在飞事务继续按旧配置走完。这样把“配置变更窗口”缩到一个明确的时点验证也好写。3.3 违例响应的时序处理违例响应这个环节我展开讲讲因为这是MPU最容易把系统“做死”的地方。对于写通道违例请求到达后地址通道AW不能直接拉低AWREADY不接收——那样上游会认为通路拥塞虽然不会死锁但会让仲裁器一直停顿。更好的处理是AW通道照常ready把请求的地址、ID、burst信息锁存到违例transaction记录里。之后W通道的数据MPU要照常接收直到WLAST期间WREADY正常拉高。这样上游看到的还是一个“正常的传输过程”。等到WLAST接收完在B通道回一个SLVERRBID必须是违例请求的AWID。对于读通道麻烦一点。R通道的响应必须严格对应该读请求。AR通道收到请求后如果检测到违例可以即时回R通道一个SLVERR。但要注意如果上游同时发了多个outstanding读请求R通道的返回顺序有严格要求——RID必须匹配。我们当时为了简化违例读请求统一回RRESPSLVERR、RDATA0、RLAST1并且保证每个请求只回一拍FIXED类型burst长度1对于INCR类型长转移则要严格按照请求的burst长度回相应拍数的R数据数据内容为0然后RLAST置位否则VIPT就会报协议错误。调试时最容易发现的问题不是“违例没拦住”而是“没违例的被误伤了”。比如一个跨越region边界的合法写比如大数据块拷贝跨越了两个放行区因为last-addr检查查到了第二个region而第一个region不覆盖该区间于是判定为违例。这类误杀要在处理policy里想清楚区域内放行的传输允许跨到相邻放行区吗如果不允许DMA搬运大块数据就得拆成两个事务软件要适配如果允许检查逻辑就要支持“多段区域复合匹配”。我们最终选择了“禁止跨区”的严格策略因为配置区域的软件最清楚自己的缓冲区是否连续。4. AI辅助研发我是怎么把大模型用出价值的这部分是标题里的重头戏。说实话AI辅助芯片研发这个话题网上讲的要么太虚“AI将取代工程师”要么太浅“用ChatGPT生成一段Verilog”。我这次实际用下来最有价值的其实是四个场景代码骨架生成、代码review、UVM验证环境生成、波形调试辅助。我一个个说。4.1 用AI生成RTL骨架省时间但别当甩手掌柜写MPU这种逻辑边界清晰的模块AI生成代码的速度确实比我手敲快一个量级。我当时的做法是先把模块端口列表、region配置寄存器布局、检查策略三条规则首地址匹配、burst last-addr抬升、master_mask过滤用自然语言描述给它让它生成SystemVerilog。第一次生成的代码能用吗能编译但有个致命问题它把检查逻辑写成了组合逻辑直接插在awvalid awready的握手链路上而且没有考虑outstanding场景。上游已经接收请求了MPU还在组合逻辑里算会不会违例加上违例信号还要同步到B通道实际上不可能在一个周期内完成。所以我的固定动作是AI生成初版后我重画时序图把检查点改成“地址通道握手完成后的下一拍判定”然后手动补上状态机和违例记录FIFO。提示词方面我总结出一个小套路先给AI喂一段AXI协议的关键字段说明尤其ARPROT/AWPROT各位定义、outstanding、burst再给端口表再给三个使用场景的例子最后提出明确产出格式SystemVerilog、接口用interface或typedef结构体、每个case要注释。直接裸问“给我写一个AXI MPU”得到的代码90%是拿不到亚稳态、不走协议细节的玩具代码。4.2 AI当代码reviewer能抓位宽和死锁但会一本正经地胡说第二个高频用法是code review。把写好的RTL关键模块贴给AI让它按“位宽溢出、未初始化、协议违规、死锁风险”四个维度找问题。实测下来AI抓位宽溢出和协议死锁的能力真的不错。比如我早期版本里aw_len 1用的是[7:0]位宽计算AI直接指出(1awlen)需要 9bit否则长burst计算会溢出。这是个很典型的低级错误AI一眼就能看出来。但我也遇到过一次AI一本正经胡说八道。它在一段B通道逻辑里建议“当违例发生时不置BVALID等下一拍再回”这完全违反AXI的ready/valid握手约定——B通道不能凭空延迟一拍响应除非用记录来追。幸好我手头有协议规范逐条核对了它的建议否掉了。所以我的结论是AI做review可以帮你抓低级错误和提醒遗漏但协议正确性最终必须靠人对着AMBA规范确认。不要因为AI推荐就改代码它推荐的“优化”可能比原版更糟糕。4.3 用AI生成UVM验证组件省下的是sequence编写时间验证侧AI辅助的性价比最高的是sequence和测试场景描述。比如那段经典的“DMA跨两区写4KB其中第二个区域无写权限”测试我用自然语言描述给AI让它输出SystemVerilog的UVM sequence代码。AI生成的sequence骨架基本对约束部分我只需要微调地址对齐和burst参数极大节省了写样板代码的时间。但这里有个雷AI对DUT内部流水深度的理解是零它生成的scoreboard假设响应“一拍后即返回”真实环境里MPU做完违例判定、走完数据接收、再到B通道返回至少需要几个周期。如果直接拿AI生成的scoreboard去比对必然一堆假失败。我的处理是让AI生成scoreboard的检查框架然后我手工填入“期望延迟窗”参数再根据实测波形校正。这样既利用了AI的代码组织能力又不让它在关键时序环节放飞。4.4 波形调试辅助把“查代码”变成“问AI”最后说一个我自己都觉得挺玄幻的场景。项目后期调一个诡异bugDMA在读一个合法区域时偶尔会收到SLVERR概率大约5%只在连续压力测试时复现。我盯了半天的波形把关键信号贴给AI自然语言描述时序关系AI给出的嫌疑清单里有三条让我醍醐灌顶一是检查ar_hit_region是否有“命中未使能region”的情况。我代码里复用了一个region配置作为“默认禁区”但使能位没接对导致该region始终“关着”按定义未使能者不算命中——但某个地址同时落在合法region和这个“关闭的禁区”里优先级判断直接走了“未使能”应当没问题。实际上问题出在别处但这条提醒让我确认了优先级逻辑无误。二是建议我检查outstanding队列里是否混入了“违例读响应先回、合法读响应后回”的乱序。这个建议直击要害。我们发现DMA发出的两个读请求一个合法一个违例MPU对违例请求立即回SLVERR而合法请求还在内存控制器里排队导致响应乱序。AXI允许乱序返回但DMA的某些配置不支持乱序于是一收到SLVERR就把整个DMA链路重置了。最后我把违例响应也设计成“记录后按顺序回”在返回路径上加了重排序缓冲问题消失。三是AI提醒我检查“配置commit与在飞事务的race”。这也是我们实际处理过的问题虽然这次不是根因但AI能主动想到这种竞态说明它对硬件世界的基本法则是有建模的。我的体会是AI在调试阶段最大的价值不是直接告诉你答案而是像一个读过无数代码、见过无数bug的同行给你列“排查方向清单”。比一个人盯着波形效率高很多。5. 验证与调试实录几个让你血压升高的坑验证环境和测试用例这里我把现场实录和踩坑经验都写出来。如果你打算照着自己的项目来一遍这里应该是信息密度最高的部分。5.1 验证环境怎么搭验证环境用的是UVM主设备和从设备都挂标准AXI VIP。DUT是MPU上游接一个AXI master VIP模拟CPU/DMA下游接AXI slave VIP模拟SRAM。scoreboard里维护一份和硬件同步的region配置镜像每个激励事务发出前先在scoreboard里计算期望结果放行/违例以及违例时的期望响应随后对VIP的B/R通道响应做比对。覆盖点我是这么拆的地址边界覆盖region内首地址、末地址、region边界-1、burst长度覆盖1、2、4、8、16、burst类型覆盖FIXED、INCR、WRAP、ID覆盖白名单内、白名单外、PROT覆盖Secure/Non-secure、特权/非特权、违例类型覆盖区域未命中、读违例、写违例、Secure违例、以及跨区域覆盖INCR跨到放行区、跨到禁区、跨出内存地址范围。随机化配置时我强烈建议做一个约束region与region之间要么完全不相交、要么完全包含禁止部分重叠。因为部分重叠时优先级逻辑虽然定了但软件配置哪个优先很容易把自己绕晕。把验证约束和软件使用指南统一起来比单纯把逻辑做对更能避免后面的联调纠纷。5.2 经典bug实录一仲裁器吞了PROT位这个bug排查了整整一天。现象是CPU发Non-secure访问应该被拒但实际放行了DMA发Secure访问应该放行却被拒了。先查MPU逻辑再查region配置系数都正常最后拿波形对比完发现仲裁器在两个master合流时居然把ARPROT/AWPROT的bit1Secure位和另一条信号的bit重叠了。仲裁器的RTL对PROT的处理是{p1[0], p2[1]}这种拼接直接把两个master的PROT位串了。这个bug的教训是集成MPU之前你必须先验证“上游总线矩阵/仲裁器是否完整透传PROT和ID”。不要假设路径上所有组件都对AXI信号完美透传。我后来建议设计团队在仲裁器的AR/AW通道加一条断言s_arprot m_arprot处理过的除外跑回归时这个断言能立刻暴露类似问题。5.3 经典bug实录二违例响应乱序害死DMA这就是前面提到过的DMA 5%概率收到SLVERR的bug。根因是违例响应没有做重排序直接提前返回。修复方案是在MPU里增加一个FIFO所有事务无论违例与否都按接收顺序记录违例事务等FIFO头位置到达后再回响应合法事务走正常内存路径。这个改动增加了几个周期的响应延迟但对AXI顺序一致性有要求的master是必须的。量产内存路径上插FIFO会带来时序压力我们的解决办法是响应重排FIFO只做“乱序修复”不做“全量排队”对于完全顺序要求的master可以在上游直接配置axprot或通过ID过滤方式关闭outstanding对于允许乱序的master比如CPU侧可以关闭重排、加速响应。5.4 常见问题速查表现象排查方向处理方式违例请求未被拦截仲裁器PROT/ID透传是否正确添加透传断言排查上游逻辑合法请求被误拦region重叠、last-addr检查过严核对region配置优先级调整burst跨越策略系统挂死、DMA无响应违例响应未回、或响应乱序检查B/R通道响应生成增加重排序FIFO偶发违例、概率复现配置commit竞态、outstanding乱序增加配置同步机制、顺序约束SLVERR计数异常状态寄存器锁存是否可靠增加违例状态锁存与中断上报6. 一点实实在在的收尾体会最后说个我自己的习惯。MPU这种东西特别适合拿来当AI辅助开发的“第一个吃螃蟹项目”因为它的检查项固定、逻辑边界清晰、协议约束明确AI生成的代码review成本低出错了也容易定位。但真正把MPU做到能上系统的水平靠的还是工程师对AXI协议的敬畏和对总线行为边界的理解。我用AI大模型辅助开发的最大心得是把AI当“高产的实习生”而不是“全知的老师”。它帮你写初版、找低级错误、列排查方向都是省时间的好帮手但涉及协议语义、系统集成、时序约束这些硬骨头AI目前还替代不了人。我现在的固定流程是让AI写第一版我负责做三件事——对照AMBA规范逐条检查、对着波形验证关键路径、把边界和竞态补上。这套流程跑下来MPU从设计到验证收敛比预想快了至少三分之一关键是没有在功能上翻车。如果你正准备给自己的片上内存加权限控制可以参考这个思路从简到繁搭一版先做一个单region、单检查点的最小验证跑通了再扩展多region、多master场景。这个迭代路径稳得很。 为片上内存加一道AXI MPU：设计、验证与AI辅助开发实践
前阵子干了个挺磨人的活儿给片上SRAM前面加了一道 AXI MPUMemory Protection Unit也就是给片上内存加一道权限检查。整个过程还拉上AI大模型当了一把“外援工程师”从RTL设计、UVM验证到波形调试都掺和了一遍。做下来最大的感受是MPU本身的逻辑不复杂但把它塞进SoC总线矩阵里要和AXI协议、仲裁器、DMA、CPU这些角色咬合好坑全藏在细节里。这个项目适合谁参考呢做SoC集成、IC前端设计、FPGA原型验证的同学尤其是准备在自己设计里加安全隔离、权限控制又不太想从零手写总线检查逻辑的这篇应该能帮上忙。我会把MPU的设计思路、AXI通道上的检查点、违例处理策略、AI辅助开发的实操方法以及验证时踩过的几个坑都摊开来讲。1. 为什么非得在内存前面加一道门1.1 多主共享片上内存的混乱现场先还原一下项目里的真实场景。一颗小规模的SoC里CPU、DMA0、DMA1 三个主设备都要访问同一块片上SRAM。最初的做法很简单挂一个带优先级仲裁的 AXI 仲裁器谁发请求谁就能读能写仲裁器只管分时复用总线根本不看请求合不合法。问题很快就暴露了。DMA在做外设搬运时如果描述符里的源地址或者长度配错了DMA就会朝着片上SRAM的任意地址一顿写。运气好时写的是未使用区域静默覆盖后面查数据对不上才反应过来运气不好直接写到CPU的中断向量表、栈指针所在的地址区域整个系统跑飞。更要命的是两个DMA同时运行如果软件配置不当DMA0完全有可能把DMA1正在使用的数据缓冲区改掉这种问题复现难、排查难因为出事的时候大家第一反应是“软件配置有问题”但硬件上没有任何兜底手段。这个需求其实不是我们拍脑袋想出来的。稍微大一点的SoC安全隔离、多域共享、功能安全场景里MPU几乎是标配。ARM、RISC-V 处理器内核里的MPU管的是内核视角的地址空间访问控制而我们这里的MPU是站在总线层面对发往内存的所有 AXI 事务做权限检查。二者不是替代关系而是互补处理器MPU管软件bug总线MPU管一切主设备的非法访问包括外设、DMA、调试接口。1.2 AXI请求里其实自带“身份信息”很多人以为权限检查很难做其实AXI协议在请求侧已经给了我们足够的信息关键是你会不会用。以 AXI4 的写通道为例主设备发出写请求时AWADDR带上目标地址AWLEN和AWSIZE决定了这次传输有多少拍、每拍多少字节AWID用于标识这是哪个master或哪条outstanding事务AWPROT则携带了安全/特权/数据指令属性。这些信号组合起来其实就是一份完整的“访问意图说明书”谁AWID、要去哪AWADDR、要干嘛读写由AW/AR通道区分、带宽多大LEN*SIZE、以什么权限访问AWPROT。MPU要做的就是用这份“说明书”去对照一组预先配置好的规则。规则描述的是某个地址区域允许哪些主设备访问、允许读还是写、是否要求Secure属性、是否允许非特权访问。匹配通过就放行不匹配就拦下来同时回一个错误响应告诉发起方“你的访问被拒了”。顺着这个思路MPU可以被拆成三件套地址区域匹配、权限校验、违例响应生成。后面每一块我都会展开讲。2. 权限检查逻辑到底怎么设计2.1 地址区域匹配mask 还是 basesize在动手写RTL之前先解决一个基础问题区域配置寄存器用掩码mask方式还是基地址大小basesize方式。掩码方式的规则是(addr ^ base) ~mask 0也就是地址与基地址逐位异或后被掩码覆盖的位必须全为0。它的好处是只用一个比较器加上一些逻辑门就能完成匹配面积小、路径短非常适合对时序敏感的总线路径。代价是区域大小必须是2的幂次而且对齐要求严格。比如你只想保护一张256字节的配置表如果它恰好不落在自然对齐的256字节边界上mask方式就很难精确表达。basesize方式更直观addr base addr base size。它可以保护任意大小、任意对齐的地址区间但比较器要多做一个加法器和两级比较路径更长。对片上SRAM这种动辄64KB、128KB的内存我通常会选择basesize方式因为实际使用中很难保证每一个需要保护的缓冲区都恰好是2的幂次对齐。如果做的是Cache、TCM这类天然对齐的存储mask方式更省面积。实际项目里我两种都写过最后拍板用basesize理由很实际需求方总是会提出一些“不规整”的保护区间比如“从0x8000_1000开始大小0x2A00”你用mask表示试试要么扩区间保护了不想保护的地址要么拆成多个region。basesize虽然硬件贵一点但软件配置灵活验证也直观。2.2 region匹配的优先级与重叠处理区域配置通常是多组的比如8组或者16组。多组就绕不开一个问题如果一个访问地址同时落在多个区域配置里以谁为准硬件上必须有一个确定的优先级约定否则验证没法写。常规做法是固定编号优先比如region0优先级最高region15最低匹配时从高优先级到低优先级逐个比较一旦命中最高的那个就停止。还有一个惯例未使能的region直接算“未命中”不参与比较。软件使用上还有一个容易忽略的点如果一个低优先级区域是“限制区”比如禁止访问而高优先级区域是“放行区”那么放行区的配置必须把边界收紧不能让禁区的地址被更高优先级的区域“覆盖”后放行。这一点我会在验证章节里专门讲因为随机配置下非常容易踩。2.3 违例响应怎么选SLVERR、静默丢弃还是中断检查不过的请求怎么处理是设计MPU时最容易想当然、也最容易出错的地方。新手第一反应是“拦下来不就行了”但AXI协议有个铁律每个请求必须有且仅有一个响应。你可以在地址通道把请求挡在门外但发起方还在等待响应等不到就会挂死——DMA可能一直在重试CPU可能一直停在总线上。所以MPU必须给违例的请求生成一个“合法”的响应。AXI4 里最合适的违例响应就是 SLVERRslave error0b10。对应的读通道在RRESP上回SLVERRRLAST必须照常置位RLAST的拍数和违例请求的burst长度严格一致写通道则在B通道回SLVERR。这里有个细节写通道处理违例请求时数据仍然可能已经在W通道上传到了MPUMPU不能私下丢弃W通道数据而是要继续接收完整个write data burst照常置WREADY到B通道再回错误。如果中途把WREADY拉低主设备会因为数据发不出去而卡住。响应完之后要不要打断CPU通常要。我们的做法是违例事件发生时除了回SLVERR还拉一个mpu_violation_intr中断给CPU同时把违例的地址、请求ID、读/写方向、命中的region编号锁存到状态寄存器里。中断的作用是让软件能及时感知非法访问而不是等系统功能出错了才回头查。这里还要提一个非常有用的调试模式fail-open。正常工作下MPU命中违例就拦截、报错调试模式下可以配置成“不拦截、只记录违例信息、继续放行”。这个模式对定位软件问题极有价值因为有些违例是因为DMA描述符配错了直接拦截会导致系统状态变化原始现场就丢了。先fail-open抓到脏数据再fail-closed修正能省大量联调时间。3. 核心模块实现RTL细节与AXI通道咬合3.1 模块边界与端口规划MPU插在内存控制器之前还是之后是有讲究的。两种做法我都试过。挂在内存控制器之后MPU只管内存控制器收到的请求好处是挡不住未经内存控制器访问的外设——如果总线上还有别的路径能绕过内存控制器到达SRAM这条路就漏了。挂在仲裁器之前、每个主设备的请求入口处检查最安全但代价是每个入口都要一份检查逻辑面积翻倍。实际工程里最常见的是在仲裁器输出侧、内存控制器入口挂一个集中式MPU。仲裁器已经把多个master的请求汇聚成一个单口事务流MPU在这个点只处理一个通道逻辑简单、面积小。但要留意仲裁器在合并请求流的时候会不会丢掉或者改写PROT、ID信息如果会MPU就查了个寂寞。所以选这个方案时要先确认仲裁器是否透传ARPROT/AWPROT我是踩过这个坑的后面验证章节会细说。端口设计上MPU本质上是个AXI slave口进、AXI slave口出从内存控制器视角看是master侧但对外呈现为一个“可配置的旁路网关”。核心端口如下端口组方向说明s_axi_*输入来自仲裁器的AXI请求含AR/AW的ADDR、ID、PROT、LEN、SIZE等m_axi_*输出送往内存控制器的AXI请求放行时原样透传cfg_*输入配置接口挂CSR总线用来读写各region的基地址、大小、权限位violation_stat输出违例信息锁存包含地址、ID、方向、命中的region编号violation_intr输出违例中断请求1脉冲或电平可选3.2 检查逻辑的SystemVerilog骨架我先把最核心的检查逻辑骨架贴出来。这个版本是给AI辅助生成的初版我后来做了裁剪加上了关键注释module axi_mpu #( parameter int NUM_REGIONS 8, parameter int ADDR_W 32, parameter int ID_W 4 ) ( input logic clk, input logic rst_n, // AXI slave侧来自上游 input logic [ID_W-1:0] s_awid, input logic [ADDR_W-1:0] s_awaddr, input logic [7:0] s_awlen, input logic [2:0] s_awsize, input logic [2:0] s_awprot, input logic s_awvalid, output logic s_awready, // ... W、B、AR、R通道略 output logic violation_intr ); // region配置数组基地址、大小、使能、读写权限、安全属性、master白名单 typedef struct packed { logic en; logic [ADDR_W-1:0] base; logic [ADDR_W-1:0] size; logic read_ok; logic write_ok; logic secure_only; logic [2**ID_W-1:0] master_mask; } region_cfg_t; region_cfg_t cfg [NUM_REGIONS]; // 配置寄存器读写逻辑请自行补全这里不展开 // 1) 区域匹配命中返回region编号未命中返回NUM_REGIONS function automatic int find_hit_region( logic [ADDR_W-1:0] addr ); int hit NUM_REGIONS; for (int i 0; i NUM_REGIONS; i) begin if (cfg[i].en addr cfg[i].base addr cfg[i].base cfg[i].size) begin hit i; break; // 优先级region编号小者优先 end end return hit; endfunction // 2) 权限检查输出是否违例以及命中的region logic aw_violation; logic ar_violation; int aw_hit_region; int ar_hit_region; logic [ADDR_W-1:0] aw_addr; logic [ADDR_W-1:0] ar_addr; assign aw_violation (aw_hit_region NUM_REGIONS) || // 未命中任何区域默认拒绝 (!cfg[aw_hit_region].write_ok) || (cfg[aw_hit_region].secure_only s_awprot[1]) || // non-secure访问被拒 (!cfg[aw_hit_region].master_mask[s_awid]); // 如果burst跨越区域边界还要额外做地址抬升检查 // last_addr aw_addr ((1s_awlen) s_awsize)超出上限同样拒 // ar通道逻辑与aw完全对称不再重复粘贴 // 3) 违例响应生成 // 写违例继续接收W数据到WLASTB通道回SLVERR不向内存发起写 // 读违例R通道回SLVERRRLAST与请求长度对齐DATA读返回常量 endmodule这段骨架看起来简单但真把它填完整会有几个非常折磨人的细节。第一个是burst边界抬升检查。片上内存经常出现这种情况一次INCR类型的burst从区域A内部开始burst长度8每拍4字节地址一路涨涨到最后已经跨出区域A的边界甚至冲进了区域B。如果只查首地址后续拍就漏了。我们的做法是在检查逻辑里算一下“last beat地址”logic [ADDR_W-1:0] aw_burst_bytes; logic [ADDR_W-1:0] aw_last_addr; assign aw_burst_bytes ({8h00, s_awlen} 1b1) s_awsize; assign aw_last_addr s_awaddr aw_burst_bytes - 1;然后这个aw_last_addr也要参与区域匹配。也就是说一次写请求需要同时满足首地址落在合法区域内而且最后一拍地址仍然落在同一个region的合法范围内。这个方法比逐拍检查省逻辑而且完全覆盖了地址单调递增的INCR和FIXED类型。对WRAP类型的burst因为回绕地址一定落在首地址对齐的地址块内只要burst总长不跨越子块边界首地址检查基本能兜住但为了保险我还是会对last_addr做一次检查。第二个是ID过滤的粒度问题。AXI的ID是事务标签不是严格的“主设备编号”。一个master可以在不同时刻发不同ID的outstanding事务甚至软件可以通过不同ID配置不同的QoS。所以MPU的master_mask不能简单按“谁是谁”来配而应该按业务场景来配。比如“所有ID为0、1、2的请求都来自CPU子系统允许全权限”“ID为0xC的请求来自调试接口禁止访问安全区”。这个表是SoC集成时统一规划的配置错了比逻辑错了更难查。第三个是配置寄存器的同步问题。MPU的region配置不是恒定不变的软件运行中会动态调整。如果配置更新发生在有outstanding事务在飞的时刻可能出现一种竞态旧请求在检查阶段读到的还是旧配置新请求已经用了新配置行为不一致很难复现。我们的做法是提供一个cfg_commit寄存器软件先改各region的shadow配置全部就绪后写commit寄存器一次性生效生效前当前拍的在飞事务继续按旧配置走完。这样把“配置变更窗口”缩到一个明确的时点验证也好写。3.3 违例响应的时序处理违例响应这个环节我展开讲讲因为这是MPU最容易把系统“做死”的地方。对于写通道违例请求到达后地址通道AW不能直接拉低AWREADY不接收——那样上游会认为通路拥塞虽然不会死锁但会让仲裁器一直停顿。更好的处理是AW通道照常ready把请求的地址、ID、burst信息锁存到违例transaction记录里。之后W通道的数据MPU要照常接收直到WLAST期间WREADY正常拉高。这样上游看到的还是一个“正常的传输过程”。等到WLAST接收完在B通道回一个SLVERRBID必须是违例请求的AWID。对于读通道麻烦一点。R通道的响应必须严格对应该读请求。AR通道收到请求后如果检测到违例可以即时回R通道一个SLVERR。但要注意如果上游同时发了多个outstanding读请求R通道的返回顺序有严格要求——RID必须匹配。我们当时为了简化违例读请求统一回RRESPSLVERR、RDATA0、RLAST1并且保证每个请求只回一拍FIXED类型burst长度1对于INCR类型长转移则要严格按照请求的burst长度回相应拍数的R数据数据内容为0然后RLAST置位否则VIPT就会报协议错误。调试时最容易发现的问题不是“违例没拦住”而是“没违例的被误伤了”。比如一个跨越region边界的合法写比如大数据块拷贝跨越了两个放行区因为last-addr检查查到了第二个region而第一个region不覆盖该区间于是判定为违例。这类误杀要在处理policy里想清楚区域内放行的传输允许跨到相邻放行区吗如果不允许DMA搬运大块数据就得拆成两个事务软件要适配如果允许检查逻辑就要支持“多段区域复合匹配”。我们最终选择了“禁止跨区”的严格策略因为配置区域的软件最清楚自己的缓冲区是否连续。4. AI辅助研发我是怎么把大模型用出价值的这部分是标题里的重头戏。说实话AI辅助芯片研发这个话题网上讲的要么太虚“AI将取代工程师”要么太浅“用ChatGPT生成一段Verilog”。我这次实际用下来最有价值的其实是四个场景代码骨架生成、代码review、UVM验证环境生成、波形调试辅助。我一个个说。4.1 用AI生成RTL骨架省时间但别当甩手掌柜写MPU这种逻辑边界清晰的模块AI生成代码的速度确实比我手敲快一个量级。我当时的做法是先把模块端口列表、region配置寄存器布局、检查策略三条规则首地址匹配、burst last-addr抬升、master_mask过滤用自然语言描述给它让它生成SystemVerilog。第一次生成的代码能用吗能编译但有个致命问题它把检查逻辑写成了组合逻辑直接插在awvalid awready的握手链路上而且没有考虑outstanding场景。上游已经接收请求了MPU还在组合逻辑里算会不会违例加上违例信号还要同步到B通道实际上不可能在一个周期内完成。所以我的固定动作是AI生成初版后我重画时序图把检查点改成“地址通道握手完成后的下一拍判定”然后手动补上状态机和违例记录FIFO。提示词方面我总结出一个小套路先给AI喂一段AXI协议的关键字段说明尤其ARPROT/AWPROT各位定义、outstanding、burst再给端口表再给三个使用场景的例子最后提出明确产出格式SystemVerilog、接口用interface或typedef结构体、每个case要注释。直接裸问“给我写一个AXI MPU”得到的代码90%是拿不到亚稳态、不走协议细节的玩具代码。4.2 AI当代码reviewer能抓位宽和死锁但会一本正经地胡说第二个高频用法是code review。把写好的RTL关键模块贴给AI让它按“位宽溢出、未初始化、协议违规、死锁风险”四个维度找问题。实测下来AI抓位宽溢出和协议死锁的能力真的不错。比如我早期版本里aw_len 1用的是[7:0]位宽计算AI直接指出(1awlen)需要 9bit否则长burst计算会溢出。这是个很典型的低级错误AI一眼就能看出来。但我也遇到过一次AI一本正经胡说八道。它在一段B通道逻辑里建议“当违例发生时不置BVALID等下一拍再回”这完全违反AXI的ready/valid握手约定——B通道不能凭空延迟一拍响应除非用记录来追。幸好我手头有协议规范逐条核对了它的建议否掉了。所以我的结论是AI做review可以帮你抓低级错误和提醒遗漏但协议正确性最终必须靠人对着AMBA规范确认。不要因为AI推荐就改代码它推荐的“优化”可能比原版更糟糕。4.3 用AI生成UVM验证组件省下的是sequence编写时间验证侧AI辅助的性价比最高的是sequence和测试场景描述。比如那段经典的“DMA跨两区写4KB其中第二个区域无写权限”测试我用自然语言描述给AI让它输出SystemVerilog的UVM sequence代码。AI生成的sequence骨架基本对约束部分我只需要微调地址对齐和burst参数极大节省了写样板代码的时间。但这里有个雷AI对DUT内部流水深度的理解是零它生成的scoreboard假设响应“一拍后即返回”真实环境里MPU做完违例判定、走完数据接收、再到B通道返回至少需要几个周期。如果直接拿AI生成的scoreboard去比对必然一堆假失败。我的处理是让AI生成scoreboard的检查框架然后我手工填入“期望延迟窗”参数再根据实测波形校正。这样既利用了AI的代码组织能力又不让它在关键时序环节放飞。4.4 波形调试辅助把“查代码”变成“问AI”最后说一个我自己都觉得挺玄幻的场景。项目后期调一个诡异bugDMA在读一个合法区域时偶尔会收到SLVERR概率大约5%只在连续压力测试时复现。我盯了半天的波形把关键信号贴给AI自然语言描述时序关系AI给出的嫌疑清单里有三条让我醍醐灌顶一是检查ar_hit_region是否有“命中未使能region”的情况。我代码里复用了一个region配置作为“默认禁区”但使能位没接对导致该region始终“关着”按定义未使能者不算命中——但某个地址同时落在合法region和这个“关闭的禁区”里优先级判断直接走了“未使能”应当没问题。实际上问题出在别处但这条提醒让我确认了优先级逻辑无误。二是建议我检查outstanding队列里是否混入了“违例读响应先回、合法读响应后回”的乱序。这个建议直击要害。我们发现DMA发出的两个读请求一个合法一个违例MPU对违例请求立即回SLVERR而合法请求还在内存控制器里排队导致响应乱序。AXI允许乱序返回但DMA的某些配置不支持乱序于是一收到SLVERR就把整个DMA链路重置了。最后我把违例响应也设计成“记录后按顺序回”在返回路径上加了重排序缓冲问题消失。三是AI提醒我检查“配置commit与在飞事务的race”。这也是我们实际处理过的问题虽然这次不是根因但AI能主动想到这种竞态说明它对硬件世界的基本法则是有建模的。我的体会是AI在调试阶段最大的价值不是直接告诉你答案而是像一个读过无数代码、见过无数bug的同行给你列“排查方向清单”。比一个人盯着波形效率高很多。5. 验证与调试实录几个让你血压升高的坑验证环境和测试用例这里我把现场实录和踩坑经验都写出来。如果你打算照着自己的项目来一遍这里应该是信息密度最高的部分。5.1 验证环境怎么搭验证环境用的是UVM主设备和从设备都挂标准AXI VIP。DUT是MPU上游接一个AXI master VIP模拟CPU/DMA下游接AXI slave VIP模拟SRAM。scoreboard里维护一份和硬件同步的region配置镜像每个激励事务发出前先在scoreboard里计算期望结果放行/违例以及违例时的期望响应随后对VIP的B/R通道响应做比对。覆盖点我是这么拆的地址边界覆盖region内首地址、末地址、region边界-1、burst长度覆盖1、2、4、8、16、burst类型覆盖FIXED、INCR、WRAP、ID覆盖白名单内、白名单外、PROT覆盖Secure/Non-secure、特权/非特权、违例类型覆盖区域未命中、读违例、写违例、Secure违例、以及跨区域覆盖INCR跨到放行区、跨到禁区、跨出内存地址范围。随机化配置时我强烈建议做一个约束region与region之间要么完全不相交、要么完全包含禁止部分重叠。因为部分重叠时优先级逻辑虽然定了但软件配置哪个优先很容易把自己绕晕。把验证约束和软件使用指南统一起来比单纯把逻辑做对更能避免后面的联调纠纷。5.2 经典bug实录一仲裁器吞了PROT位这个bug排查了整整一天。现象是CPU发Non-secure访问应该被拒但实际放行了DMA发Secure访问应该放行却被拒了。先查MPU逻辑再查region配置系数都正常最后拿波形对比完发现仲裁器在两个master合流时居然把ARPROT/AWPROT的bit1Secure位和另一条信号的bit重叠了。仲裁器的RTL对PROT的处理是{p1[0], p2[1]}这种拼接直接把两个master的PROT位串了。这个bug的教训是集成MPU之前你必须先验证“上游总线矩阵/仲裁器是否完整透传PROT和ID”。不要假设路径上所有组件都对AXI信号完美透传。我后来建议设计团队在仲裁器的AR/AW通道加一条断言s_arprot m_arprot处理过的除外跑回归时这个断言能立刻暴露类似问题。5.3 经典bug实录二违例响应乱序害死DMA这就是前面提到过的DMA 5%概率收到SLVERR的bug。根因是违例响应没有做重排序直接提前返回。修复方案是在MPU里增加一个FIFO所有事务无论违例与否都按接收顺序记录违例事务等FIFO头位置到达后再回响应合法事务走正常内存路径。这个改动增加了几个周期的响应延迟但对AXI顺序一致性有要求的master是必须的。量产内存路径上插FIFO会带来时序压力我们的解决办法是响应重排FIFO只做“乱序修复”不做“全量排队”对于完全顺序要求的master可以在上游直接配置axprot或通过ID过滤方式关闭outstanding对于允许乱序的master比如CPU侧可以关闭重排、加速响应。5.4 常见问题速查表现象排查方向处理方式违例请求未被拦截仲裁器PROT/ID透传是否正确添加透传断言排查上游逻辑合法请求被误拦region重叠、last-addr检查过严核对region配置优先级调整burst跨越策略系统挂死、DMA无响应违例响应未回、或响应乱序检查B/R通道响应生成增加重排序FIFO偶发违例、概率复现配置commit竞态、outstanding乱序增加配置同步机制、顺序约束SLVERR计数异常状态寄存器锁存是否可靠增加违例状态锁存与中断上报6. 一点实实在在的收尾体会最后说个我自己的习惯。MPU这种东西特别适合拿来当AI辅助开发的“第一个吃螃蟹项目”因为它的检查项固定、逻辑边界清晰、协议约束明确AI生成的代码review成本低出错了也容易定位。但真正把MPU做到能上系统的水平靠的还是工程师对AXI协议的敬畏和对总线行为边界的理解。我用AI大模型辅助开发的最大心得是把AI当“高产的实习生”而不是“全知的老师”。它帮你写初版、找低级错误、列排查方向都是省时间的好帮手但涉及协议语义、系统集成、时序约束这些硬骨头AI目前还替代不了人。我现在的固定流程是让AI写第一版我负责做三件事——对照AMBA规范逐条检查、对着波形验证关键路径、把边界和竞态补上。这套流程跑下来MPU从设计到验证收敛比预想快了至少三分之一关键是没有在功能上翻车。如果你正准备给自己的片上内存加权限控制可以参考这个思路从简到繁搭一版先做一个单region、单检查点的最小验证跑通了再扩展多region、多master场景。这个迭代路径稳得很。