想写这篇文章有些日子了，只不过一直没抽空下手。俗话说“人非圣贤，孰能无过”，咱们这些成天和元 器件打交道的硬件工程师们也能免有犯傻做错事的时候，尤其在开发设计如火如荼进行时，一些小细节的疏忽也会酿成大错。做了错事不要紧，知错就改那才是“好 孩子”。因此，这个工程更改管理（Engineering Change Management） 也显得很重要。

初接触这个概念，应该是在Quartus II_handbook的Volume 2中，那里花了一个大Section在讨论这个问题，尽管它的侧重点应该是强调Quartus II在Fitter后如何更有效的使用Chip Planner进行布局布线的进一步优化。那会特权同学也并没有领会这个概念，直接在翻过数页后pass了。 直到最近在《Rapid System Prototyping with FPGAs》中再次看 到了这个概念，在翻译3.2.1小节时有如下一段译文：

添加任何新的需求都要通过工程更改单(ECO)的方式实现。 新的需求对设计的潜在影响有哪些？是额外的资源吗？是否会影响工程的日常安排？FPGA设计性质决 定了不可能在工程设计的早期就能提供一份“完整”的设计需求，需求就好像一个“移动的目标”。我们的目的是限制这个目标移动的范围和速度。如果需求更新没 有一套完善的规则和既定的手续，并且在需求到达关键设计模块之前工程已经启动或者需求更改过于容易，那么会由于工程“流失”导致过去的努力都付诸东流。

尽管它提到的是工程更改单的问题，但是其实工程更改单也就是工程更改管理的一部分。之所有引起特权 同学的注意，那是因为想到了在硬件开发设计中一直纠缠不清的《技术更改/通知单》。一直对这个文件 是既爱又恨，写得最多的是在焊接说明上，总是有这样那样的清单上和实际元器件名称不匹配或者元器件不到位需要替代等等此类问题，所以焊接完的质检一关总是 很难过，就必须重新发一份各方签字认可的《技术更改/通知单》。恨是因为有时问题是无中生有，尽管 也许是自己工作做得不到位，关键的是它有时很耽误事，总让人感觉有些不爽。爱是因为这种做法也的的确确能够解决问题并且彻底解决问题，是一种很管用的管理 方式。

下面来看看Quartus II中所述的工 程更改管理是如何实现的。在Chip Planner下对图1做 图2的更改，只是拖动一个寄存器，然后点击“Check and Save All Netlist Changes”，Quartus II只 用很短的时间进行更改后的局部编译。

图1

图2

如图3所示，在窗口Change Manager里，可以看到刚才做的更改，里面的详细参数就不介绍，看一眼也就能明白。

图3

在Altium Designer下，其实 也有这么一个很实用的工程更改管理功能。对于图4的原理图，稍微做了如图5所示的更改，移动了TDI的位置。

图4

图5

查看菜单栏ProjectàLocal HistoryàShow Local History…，便可以得到刚才前后两次变化的对比，并定位到这两处位置。

图6

工具的功能各有千秋，主要的还是要为我们这些设计师服务。这些功能其实都是为了更有效的控制工程更 改，给工程师一个做出错误更改后反悔的机会，或者也是为了给工程师一个更改前后对比的机会。