2026年集创赛想用紫光同创PG2L做「RISC-V软核+自定义NPU指令扩展」，评委最反感哪种「拼凑式集成」？

先说评委最容易皱眉的一类做法：把开源核、自己写的NPU、DDR控制器、几个外设各自挂到总线上，地址一分配，跑通一个矩阵乘demo，然后答辩PPT写「异构融合」。问题不在技术含量不够，而在于你从头到尾没回答「为什么要异构」「不这么设计会损失什么」。这类东西评委见太多了，甚至不需要细看RTL，问一句「你的NPU和CPU之间数据怎么流动、谁负责搬运、冲突了怎么办」就露馅。

要绕开这个坑，一个可行的思路是别把NPU当外挂，而是把它嵌进流水线语义里。比如你扩展的是自定义指令，那就要讲清楚：这条指令在译码阶段怎么被识别、发射到NPU后CPU是阻塞等待还是乱序继续、访存一致性由谁保证、异常和中断怎么回传。哪怕你只实现了一个很窄的场景，比如向量点积或小卷积，只要这条数据通路是端到端闭环的，答辩时就能讲成「指令级耦合」而不是「总线级拼接」。

总线带宽这块，别只报一个理论峰值。评委想听的是你的仲裁策略和背压处理：主设备有取指、数据访存、NPU DMA三路，你怎么定优先级，NPU突发传输时会不会把CPU饿死，写响应通道拥塞时NPU是排队还是丢包重传。这些都是能落到代码和波形上的东西。

还有个容易被忽略的风险：紫光同创的工具链和开源核的适配。PG2L的IP和约束跟Xilinx那套差别不小，综合时序、跨时钟域、DDR的MIG类IP配置都可能卡你很久。建议留出至少三分之一时间做板级联调，别把时间全压在设计上。你们现在RISC-V核选的是哪一款，是纯Verilog的还是带SoC外壳的那种？这决定了你改流水线的自由度。

最后一句实在话：创新点不一定要多，一个讲透就够。把「为什么这条指令必须由硬件加速、软件做为什么慢」用数据说清楚，比堆五个模块管用。

我觉得这题的关键，是把「系统级设计」翻译成评委真正想听到的东西。他们说的不是让你从零设计一套NoC，而是希望你能证明自己的架构决策是有依据的，是被约束逼出来的，而不是「因为教程这么写」。

先说个常见的误区。很多队伍答辩时喜欢强调「我们用了AXI4互联，带宽高达多少Gbps」，这恰恰暴露了拼凑思维，因为带宽是个参数，不是设计。真正体现系统级思考的是取舍：你本来可以给NPU一条独立的高带宽通路，为什么最后选择共享总线？是因为面积不够、还是因为你的负载特征根本用不上？如果你能回答「我们的NPU访存是突发式的、粒度大，共享总线的仲裁开销可以接受，省下来的LUT用来加流水线级数」，这个回答的分量完全不一样。

沿着这条线往下走，指令调度是第二个能拉开差距的地方。自定义指令扩展最怕做成「软件调用换了个马甲」——CPU发一条指令，等NPU算完，再取结果。这本质还是外设。要往深里做，你得考虑指令的发射模型：是同步阻塞、还是异步发射加完成中断、还是干脆做成类似协处理器的紧耦合接口。不同模型对流水线的影响、对编译器/汇编器的要求、对异常处理的要求都不一样。你哪怕只选一种实现，只要能把另外几种为什么不选讲清楚，就已经是系统级设计了。

再说总线带宽分配。这块最容易讲空，建议落到具体场景：假设你的NPU在做一层卷积，需要连续读特征图和权重，同时CPU可能在取指或处理控制流。这时候总线上会有几路主设备竞争。你要讲的是你的仲裁器怎么设计、有没有优先级反转的风险、NPU的长突发会不会导致CPU取指延迟超标。如果能给出一个最坏情况的分析，哪怕只是估算，也比空谈「高效互联」强得多。

工程路径上，我的建议是先把数据通路打通，用一个极简的NPU（比如只支持一种算子）跑通「取指-译码-发射-访存-回写」全流程，再做带宽和调度的优化。因为这类项目最大的风险是摊子铺太大，最后每块都半成品。紫光同创的板子资源有限，综合和时序收敛会吃掉大量时间，早点跑通比什么都重要。

至于替代做法：如果时间实在紧，可以考虑不做完整异构SoC，而是聚焦「一条自定义指令的端到端实现」，把这条指令从编译器内联、到流水线扩展、到加速器接口、到访存一致性全部做扎实。题目看起来小了，但系统级的深度反而更容易做出来，答辩也更好讲。你们目前是想冲完整SoC，还是可以接受收窄到一个算子？这个边界定下来，后面的工作量评估才好谈。

先别急着纠结「怎么讲」，我更想提醒你一个风险：评委反感的往往不是「你用了开源核」，而是你讲不清楚自己到底改动了哪一层。拼凑式集成的典型特征不是模块多，而是模块之间的耦合是假的——AXI接上了，但CPU和NPU之间没有真正的协议约定。举个具体例子：你扩展了一条自定义指令去调用NPU做卷积，那么这条指令的语义边界在哪？如果NPU算完只写回内存，CPU靠轮询flag等结果，那其实就是「软件调DMA」，评委一问「你的指令和普通store/load有什么本质区别」就答不上来。反过来，哪怕你只做一个小场景，比如让这条指令在流水线的execute级直接和NPU握手、用握手信号反压、异常走CPU的trap通路回传，这条通路就是闭环的，讲出来是「指令级耦合」。替代做法上，如果PG2L资源紧张做不了完整一致性，那就老实承认边界：说明你只保证强序、只覆盖单核单NPU、一致性由软件屏障维护，并解释为什么这个简化在你的负载下成立。这比硬吹「异构融合」可信得多。另外答辩别只放带宽数字，放一张时序图：谁发起、谁等待、冲突时谁让路。你们现在NPU和CPU的数据交互打算走共享内存还是紧耦合的私有通路？这个决定了后面所有说法。

我想把这件事拆成一条因果链来讲，因为「拼凑感」本质上是个设计动机问题，不是模块数量问题。

起点是约束。任何系统级设计都是从约束推导出来的：PG2L这块片子LUT、DSP、BRAM有多少，你的RISC-V核占了多大，留给NPU的空间还剩多少，外部DDR带宽大概什么量级。这些数字先摆出来，你的所有架构选择才有根。比如你本来想给NPU单独开一条高带宽AXI通路，但算下来互联逻辑面积超标，于是改成共享总线加一个轻量仲裁器——这个「被迫的取舍」恰恰是评委想听的东西，因为它证明你在做工程决策，而不是照抄教程。

第二步是数据流。很多人答辩时只讲「我们用了AXI」，但AXI只是搬运规则，真正决定架构的是数据从哪来、到哪去、中间谁负责。你的NPU输入是CPU算好的中间结果，还是直接从DDR读原始数据？如果是前者，CPU和NPU之间的耦合就很紧，你要考虑同步语义；如果是后者，那CPU基本只是个调度器，NPU更像独立加速器，架构故事就完全不一样了。这两种没有优劣，但你得选一个并讲清楚为什么。

第三步才轮到指令调度。自定义指令最容易翻车的地方，是把它做成了「换皮函数调用」——CPU发一条指令，然后傻等NPU算完。要摆脱这个印象，你得回答几个具体问题：这条指令在译码阶段怎么被识别？发射之后CPU是阻塞还是继续执行后续指令？如果继续执行，那依赖关系谁来管，靠编译器插屏障还是硬件记分牌？访存一致性由谁保证，NPU写完的数据CPU怎么知道是新的？异常和中断怎么回传到CPU的trap处理？

这些问题你不需要全部给出工业级答案，但至少要有一个自洽的简化方案，并且能说出简化的代价。比如你可以说：我们只支持顺序一致、NPU操作期间CPU阻塞，牺牲了并行度，但换来了验证复杂度的大幅下降，因为我们的负载是粗粒度的、加速比主要来自NPU本身而不是重叠执行。这种话评委是认的，因为它展示了你知道自己放弃了什么。

学习路径上，建议你先把RISC-V的流水线握手和AXI的valid/ready机制吃透，再动手扩指令。很多人卡住是因为同时要理解三套协议：RISC-V的、AXI的、还有自己NPU的，脑子转不过来。先把前两套跑通一个最小闭环，比如一条指令触发一次简单计算再写回寄存器，这个通了，后面加复杂度就是堆工作量而不是重新想架构。

最后提醒一句，验证路径也是系统级设计的一部分。你打算用什么证明它对？仿真跑通、上板跑通、还是有个对比基线证明加速比？评委很爱问这个，因为它直接反映你到底有没有真的把系统跑起来。你们现在有明确的性能对比基线吗，比如纯软件实现的时间？

先说个容易被忽略的点：评委反感的「拼凑」，很多时候不是集成方式的问题，而是你的约束根本没交代清楚。PG2L这块片子资源是有限的，LUT、DSP、BRAM各有多少，你的RISC-V核吃掉多少，留给NPU还剩多少，外部DDR带宽大概什么量级——这些数字你不摆出来，后面所有架构选择都像是「我想这么干」，而不是「我只能这么干」。前者是拼模块，后者才是系统设计。

举个具体的坑：很多队伍喜欢在答辩里强调「我们给NPU单独开了一条高带宽AXI通路」，听起来很牛，但评委一算你的互联逻辑面积和仲裁开销，就会问「这条通路真的用满了吗，你的NPU访存是突发大粒度还是细碎随机」。如果答不上来，这条独立通路就成了摆设。反过来，如果你能说「我本来想独立通路，但算下来LUT不够，改成共享总线加轻量仲裁，省下的资源用来加深NPU流水线，因为我们的负载是突发式的、仲裁开销可接受」——这个取舍讲出来，分量完全不一样。

再补一个风险提示：别把「创新」理解成模块堆得多。评委真正想听的是你的数据流闭环。CPU算完的中间结果怎么进NPU，算完怎么回，谁负责同步，冲突了怎么办，异常走哪条通路。哪怕你只做一个很窄的场景，比如自定义指令触发一个小卷积，只要这条通路端到端是闭环的、有握手有反压，就比堆五个IP核挂总线上强得多。

你们现在NPU的访存粒度大概是多大，是整块搬还是流式读？这个直接决定总线方案该怎么讲。