Diplomacy参数协商在核内微观设计中的疑虑

[davine47]

hi，看到XiangShan有在核内使用diplomacy进行参数协商与连线，有以下疑问： 核内设计是及其严谨的，各个端口和bit之间连线时序是严丝合缝的，以至于设计期间不可以屏蔽编译/仿真工具的warning信息，设计人员必须保证所有的warning都在自己的设计意图之内。

核外SoC的连线是宽松的，各个ip之间位宽有容忍性，diplomacy可以很好的做参数检查和协商，自动化连线，通过两阶段实例化拓展设计空间，把宽松的手动连线变得严谨。

若一旦尝试在核内使用diplomacy进行参数协商，如何保证协商网络中所有参数都是严谨的？举一个例子，我们强调敏捷化开发，当有人员快速debug修改协商网络中的参数32bits为30bits，若协商协议总是采用最小值，此时改动将影响不止一个模块，如果回归case无法捕捉到此种情况去流片，虽然不一定会错，但新参数是否真正符合所有核内模块的设计意图（不同人设计的），这很难说。

当后期协商网络很复杂时，firrtl编译各种优化，一旦有一个参数协商不符合设计意图时，优化传播会干掉一堆寄存器或逻辑，严重会影响流水线时序。反观SoC的diplomacy连线，我们会在顶层信号打上DontTouch注解，以阻断firrtl的优化传播，即使SoC连线错误也不会影响到核内逻辑。

若在核内引入diplomacy协商，再引入dontTouch注解，又会破坏我们已有的firrtl优化过程。 目前想到好的方法是由模块设计人员引入assertion来对参数进行校验，但这仍无法证明所有模块参数协商后的设计空间与之前相比是绝对符合预期的。

所以想请教下，在微观设计中引入diplomacy协商是否是合适的？或者有什么方法可消除上述顾虑？ 谢谢！ :)

[poemonsense]

听上去更多是验证不充分的问题，而不是diplomacy设计导致的问题？

[davine47]

听上去更多是验证不充分的问题，而不是diplomacy设计导致的问题？

在SoC中引入diplomacy可以明显减少验证成本，在核内微观且琐碎的逻辑中引入diplomacy，是否会增加潜在的验证成本

[davine47]

diplomacy可分为两部分，lazymodule的两阶段实例化，以及基于此的参数协商；只引入lazymodule到核内对参数进行校验实例化是没有问题的，所有改动都闭包在一个模块内。 一旦引入参数协商后，由于核内模块相比于SoC较为琐碎，极可能会产生较为复杂的协商网络 即担忧每次敏捷化集成时，验证复杂协商网络本身的正确性需要额外的验证成本

[poemonsense]

个人感觉是有可能的吧，这个就是看协商逻辑（可以看做是一种EDA工具，一种脚本）和多样化的硬件实现，两者之间的tradeoff，开销和收益，是如何评估了吧

如果协商逻辑足够通用，能够在硬件实现中平摊掉，那显然验证协商逻辑+实现通用的硬件逻辑，性价比更高；如果协商逻辑复杂又缺乏通用性，验证成本很高，那性价比可能就差了。可能要根据应用场景的现实情况来决定了

[davine47]

diplomacy协商在SoC中把宽松的连线变严谨，引入核内后感觉，使本就严谨的设计变得宽松 使用工具的同时也需要给工具做开发前评估、开发中限制 已了解，谢谢回复 :)