| For many engineers, using various tools become everyday job, sometimes we even miss in those tools. In the article, the author went through one experience of solving routing congestion in the design to l a story: a good engineer should go beyond the tools. 对许多工程师而言，各种电子辅助设计的工具占据了日常工作的各个环节，甚至迷失于电子设计就是使用各式各样工具。本文针对我们在工作中遇到的绕线拥挤问题，主要内容是一套总线四选一的布局与布线，这个布线始终存在绕线拥挤，在工具无法完成，甚至工具优化也难实现的情况下，zui后采用人工干预解决了绕线拥挤的问题。 从大学毕业被电子公司聘用、工作三四年、做了四五个项目、用过五六个工具、熟悉其中一两个，工程师似乎就这样修炼成了。但是入门之后如何再精进，是许多工程师在职业生涯中遇到的难题。本文作者介绍了过去作为EDA工程师在设计一款路由交换芯片时遇到的具体问题，自己如何努力地思考和寻找解决方案，以及在解决问题后的一些工作感想。 从技术目标的层次讲，在芯片面积之外，时序收敛、绕线拥挤、低功耗设计算是战略层面的技术问题；芯片的面积、时序、绕线、功耗的问题很可能决定了该芯片是否具备成本可行性、是否能达到技术目标、是否能实现技术项目、是否具有技术优势的战略层次抉择。相对来说，在设计过程中遇到的信号完整性、天线效应、电压降（IR-drop）等技术问题则是局域性、战术层面的问题，较少会影响到整个芯片的规划以及性能的实现。 问题的出现 2003年我们进行一款路由交换芯片项目开发时，对于其后段设计，首先初步确定了设计工艺将为0.18um 1P6M（0.18微米、一层硅六层金属纯数字代工工艺），并立刻从前端工程师得到一个框架的初步的RTL代码，马上做了一个初步的低层规划（floorplan）后，三周后定位了该项目的难度。该项目在RTL综合后，芯片预估面积已在可接受范围内，芯片由于电源供电从而低功耗要求不严，zui高频率133MHz基本能达到，*的瓶颈是其中一个模块网络处理器（NP）表现有绕线拥挤问题。 这个网络处理器模块大约有47万门、50个硬核模块、2,027个输入输出，图1a是NP模块在zui初的布局后对绕线拥挤的预估图像。 图1：（a）绕线拥挤的预估图像; （b）NP模块对绕线拥挤的预估图像。 具体的拥挤报告如表1所示（拥挤度指需要的绕线通道数与能提供的通道数之差值，正值表示不拥挤、负值表示拥挤）。 表1：问题解决之前的拥挤报告。 寻找解决方案 因为zui初的规划中，对所有的模块都采用了80%的利用率目标，从而在遇到模块级绕线拥挤问题后，选择一位工程师把这个模块作为专项来处理。首先提出了两个方案：1. 将该模块利用率从80%下降到70%，并优化该模块IO布置；2. 在原来自动布局的基础上，采用拥挤驱动布局、物理综合以及人工干预来改善拥挤度。 方案一已经影响到芯片总的规划与布局，我们在对周围模块进行调整后，在面积上接受了该模块利用率从80%下降到70%，而在IO布置上只接受了部分IO布置的优化。对第二方案则不断地尝试各种自动布局中能够找到的参数以及手工干预，确实实现了一定程度的拥挤优化。一个月后，我们的NP模块对绕线拥挤的预估图像如图1b所示。 从得到的拥挤报告可以看出绕线拥挤改善了很多，但是拥挤现象在该模块仍然存在，离目标还有一段的距离。项目进行到这个时候，前端的RTL代码已经快结束了，也就是说这个NP模块必须尽快定型，否则在该模块上的每一天耽搁就是整个项目往延后一天。 于是我们又提出了下面三个方案：1. 在项目规划上做zui坏的打算，确定该模块利用率必须降到多少以下才能够解决绕线拥挤问题；2. 把绕线拥挤问题在流程中再提前，不仅仅从后端的布局布线手段来优化拥挤，提出了能否有以绕线为优先的RTL综合方式；3. 同时要求前端设计人员写出该模块中的子模块功能、数据与控制的走线等，从而希望定位模块中问题具体点，寻找非常规解决方案。 这三个项目执行下来，时间又进行了三个礼拜，同时项目正式在时间上已经进入设计后端是关键路径了，而NP绕线拥挤则是后端项目中的关键路径。时间过得越来越多，项目进度的压力非常大，NP的绕线拥挤现在已经升级为项目成败中关键路径的关键点了。新三个方案的结果有忧有喜： 1. 对方案一的执行结果是，该模块利用率即使在40%以下依然无法解决绕线拥挤问题，从而否定了通过加大模块面积的解决方案。同时，我们在再次调整了周围模块的面积后，定下了NP模块利用率zui低可以放宽到65%。 2. 对方案二的执行结果中发现目前综合工具对解决绕线拥挤问题比较无力，我们采用了加高走线面积的预估值权重的办法，希望综合工具在做面积优化时，能够选择绕线优先的算法，这个办法被证明依然失败。 3. 只有方案三的执行结果带来了一些曙光，我们在NP的几十个子模块中确定了其中一个子模块绕线特别多，经仔细检查，这个子模块的逻辑基本上是一个1200组的四选一功能。 第三个方案的结论解释了为什么面积增大了而工具依然不能解决绕线拥挤的原因：NP整个模块中只有一个子模块特别的绕线拥挤，虽然增大面积会增加整个NP的绕线，但是对于特别拥挤的一小块地方并不是特别大的帮助。 问题定位 发现了问题的关键所在，就能制定针对这个问题的解决方法了。我们把问题局限在这主要是一个综合工具的问题，虽然标准库文件中有着标准的四选一子单元，但是综合时综合工具会把一组四选一的逻辑综合成组合逻辑。比如对于0.18um的标准库，下面一段简单mux的代码会综合成为INV、NAND2、NOR2和AOI22四种逻辑的组合。 Module mux4to1_1200 （s,data0,data1,data2,data3,data）; input [1:0] s; input [1199:0] data0,data1,data2,data3; output [1199:0] data; reg [1199:0] data; always@（s or data0 or data1 or data2 or data3） begin case（s） 2'b00 begin data=data0; end 2'b01 begin data=data1; end 2'b10 begin data=data2; end 2'b11 begin data=data3; end endcase end endmodule 这段代码如果采用直接调用mux4单元，只有6,000条绕线，而这种组合逻辑将会有9,000余条绕线。这种组合逻辑不仅带来更多的三千多条绕线，而且在其解选择信号s时，与调用单元的连接是随意的，从而造成不仅线多而且绕线非常复杂。目前综合工具基本上都没有前瞻性的对绕线优先的综合手段，从而在这种特殊情形下，出现了几乎不可能只依靠工具解决的技术问题。我们一旦明确了这点，在综合前先将这个子模块初始化成为mx4的直接调用，马上让整个NP绕线的zui拥挤点消失。 本文小结 从现在的绕线拥挤预估图像可以看出，绕线拥挤问题已经基本解决。具体的拥挤报告如表2所示。 表2：绕线拥挤问题改善后的拥挤报告。 回顾这个项目，zui终的完成时间还是比预期晚了一个月左右。造成这个进度延缓有多个原因：团队人员*次做项目，需要磨合；团队人员较少，精力分散；之前经验偏重于时序收敛而非绕线拥挤等。但是因为人员紧缺而被迫寄希望于软件工具来解决问题这个思维本身，可以说是项目延缓的zui根本原因。在我们之后的项目中，一发现问题立即追查问题的根源，让自己负起责任，而不期待工具会自动解决问题，从而我们之后的芯片项目在完成质量与完成时间上都有了较大的提高。 | |
QQ交流群
