硬件迭代开发的运作模型

迭代开发、硬件迭代、横向迭代、纵向迭代...



分类：验证团队管理

“迭代开发”是一种软件工程方法。该方法将整个产品开发过程切分成多个小的开发过程，每个小的开发过程中都包含需求、开发、验证的整套环节。而传统的瀑布式模型是完全不同的，瀑布式模型仅做一轮的需求、开发，以及验证工作。



如果想更进一步了解“迭代开发”的软件实践方式，推荐阅读《轻松Scrum之旅》。该书以讲故事的方式来描述，读起来感觉身临其境，轻松愉快。

在业界声名卓著的软件工程方法，在芯片设计领域是否依然可以再领风骚呢？这个问题，涉及到项目管理的方方面面，不是拍脑袋就可以给出答案的，待我们慢慢分析。一个好消息是，我曾经的团队使用过迭代开发的思想来设计芯片，获得了一些成绩，也受到了诸多诟病，可以算是小有相关经验了。不管是吃螃蟹，还是吃蜘蛛，总之实实在在的吃过了。今天的文章，就先从迭代的运作模型开始分析。

迭代的第一步，就是对产品开发过程的划分。一般只有两种划分方法：横向、纵向。



横向方式：每次迭代，开发一个或几个Block，例如迭代1开发Block A，迭代2开发Block B；

纵向方式：每次迭代，开发一个或几个Block的部分内部功能，例如迭代1开发Block A，Block B，Block C的接口及旁路功能。

需要说明，采用不同的迭代开发运作模式，最终的迭代次数可能会有所不同。

现在问题来了，如果你是项目经理，你更青睐那种迭代开发的运作模型呢？



项目状态介绍：图中的芯片，橙色的Block A的需求稳定，Block B的需求即将确定，Block C和Block D的需求还在讨论中。现在，你的团队开发、验证工程师，都已经到位了。现在，如果你是项目经理，你会如何考虑呢？

横向的迭代开发运作模式

一般的第一直觉是：先做已经需求确定的模块。难道让负责Block C，Block D的人都在那里“闲着”吗？需求已经确定了，就先把这些Block做出来好了。早点做出来，也可以早点上板调试不是吗？

假设我们的人力规划为：1个Block的人力资源为1个设计工程师和1个验证工程师。

假设人力都到位，一起开发Block A，是怎样一种情景呢？



“众人划桨开大船”，热火朝天的一起上，三下五除二也就把这个Block搞定了。一般规模的Block，迭代周期也就1个月，迭代完成后，可以达到拉通典型Block用例，以及模块代码覆盖率达标的程度（无功能覆盖率模型）。

搞定Block A，接下来就要搞定Block B了。此时有两种选择：

选项A：留1个验证工程师在Block A继续做验证；

选项B：大家一起去做Block B。

如果采纳选项A，那么Block B的开发就变成了4个设计工程师+3个验证工程师，人数不匹配，验证平台的开发时间会拉长；假设Block B开发完，再开发Block C，就变成4个设计工程师+2个验证工程师，验证平台的开发时间会更拉长。



如果采纳选择B，每一轮迭代人力都非常充沛，大家可以热火朝天的做完4轮迭代，真的很开心。然后，这时候，每个模块都要有一个验证负责人了。然而，从第1轮迭代结束，3个月过去了，很多信息都忘记了。



横向迭代的优势：

1、  可以最快的启动85%后续工作；

2、  可以最快的启动部分FPGA验证工作；

3、  看上去没有人力浪费（闲人）。

横向迭代的劣势：

1、  增加了每个Block的设计、验证的沟通成本，增多了设计与设计、验证与验证、验证与设计沟通的点；

2、  由于不是由一个人开发的验证平台，Block验证负责人需要接手Block整体验证平台的使用，以及验证平台的Debug；

3、  假设团队建设没有跟上，可能会产生无尽的扯皮、扯皮、扯皮，以及扯皮。

看到这里，如果你是项目经理，你还会继续选择采用横向的迭代开发运作模式吗？

纵向的迭代开发运作模式

还是面临项目开始时那个场景，人力到位了，但是需求还不稳定，怎么办？



如果如图所示，一些人已经开始启动工作了，而另一些人的需求是不稳定的，是否应该启动工作呢？怎么启动？当然，如果选择了纵向的迭代运作模式，即使需求不稳定，全面启动开发可能也是必须的选择，毕竟——人力已经到位了。如果一些人在工作，而另一些人闲着，考核评价是不公平的。



如果在每轮迭代时，每个Block都看成独立的Block，操作上会稍微容易一些。在这种情况下，系统工程师只需要说明在每个迭代中，各个Block都完成哪些module的设计就可以了。这样的模式，与之前的瀑布模式最大的区别是先完成各个module的验证工作，其余基本是一样的。当然，对每个模块都开发验证平台，工作量是远远大于仅开发Block级验证平台的（横向划分也存在一样的问题）。

如果在每轮迭代时，要求将整个ASIC看成一个整体，将各个Block连接在一起（例如图中的BlockA、Block B、Block C、Block D的function0可以连通），任务难度就会突然拔高好几个高度。将每个Block 划分出来的功能连接到一起，需要功力和运气。功力就不说了，单说运气吧，链路上可能存在一些模块，设计上本身就是一个整体。例如，一个8x8的Matrix，不可能为了拉通整个链路，先设计出一个2x2的Matrix，再将其修改为8x8。

纵向的迭代开发模式的优势：

1、  Block由专人负责，大大减小了沟通的压力；

2、  Block由专人负责，这个人对业务的理解能够达到较深的层次。

纵向的迭代开发模式的劣势：

1、  要么在需求不稳定时闲置人力；要么在需求不稳定时，就着手开发，但要承担返工的风险；

2、  完成85%网表的最长路径有可能会拉长。

结论：

1、  横向、纵向的迭代运作模式各有优缺点；

2、  横向有可能提前85%网表交付时间点；

3、  横向会极大的增加沟通成本；

4、  纵向的沟通成本最小；

5、  纵向有可能拉长85%网表交付时间点。

总之，适合自己的，才是最好的。如果我是项目（或验证）经理，我可能会更青睐沟通成本小的方式。

欢迎您在“IC验证工程师交流群”讨论（推荐），或者在公众号留言（查看不及时）。扫描下方的二维码，加入“IC验证工程师交流群”。由于群人数超过100人，目前只能通过邀请加入群聊。想加群的，先加吴杉的微信号birdshanshan，并在备注中说明加入“IC验证工程师交流群”。或者请已经加入群聊的其他人拉入即可。

本文为原创，转载请注明出处：IC验证工程师

    关注 IC验证工程师