为了满足对功率、性能和面积的要求，系统级芯片(soc)和处理器设计团队面临着挑战。随着芯片复杂度的增加，设计团队必须验证成千行的代码以获得设计信心。为了取得成功，设计团队必须在紧迫的产品上市时间内达到系统目标和验证标准。

    设计信心的增加是与独特测试序列的数量和系统级测试完整性呈函数关系。随着rtl修改的减少，功能验证投入增加，从而产生一种“已测试”模块。此时，仿真测试工具要花几天或几周时间完成，并且对设计改变非常敏感。功能验证中的确认要用数以亿计的仿真向量才能实现，难怪设计工程师临近设计末期都拒绝做出改变。

    但是，如果最初的布局和布线结果显示设计不满足系统时序或功率目标怎么办？经过评估，设计工程师可能得出结论：通过对数据路径的检查，或许需要控制逻辑！这可能是一个简单的改变或一次重要的重写。恐惧之处在于重新验证经修改的设计需要多少工作，并且所做的改变让所有过去的功能验证投资付之东流水。

    在这些境况下，大多数工程师主张做尽可能最少的侵入性改变。然而，这可能引起问题：在全局环境下简单修正在局部实现上变得复杂，或者使风险最小的修正可能不完全满足系统标准，且需要多次反复改变。对rtl的任何改变，无论有多小，都可能引入细微的负面影响。

    连续改变(sequential change)

    在大多数情况下，设计工程师通过把微架构转换到rtl代码来满足时序、功率和面积目标，微架构转换是连续的修改。当rtl模型经历优化时，设计工程师对关键设计功能如缓存大小、管线(pipeline)的数量和功率管理执行“what-if”分析。

    在soc和处理器设计中，功率、时序和面积特性难以评估和折衷。可供选择的微架构具有大量不同的数据路径，而控制逻辑的实现需要付出大量的工作进行开发和验证。

    仿真可以被用于验证微架构优化。然而，仿真测试工具要运行数周，而连续的改变可能让现有的测试基准(testbench)失效。测试基准的效用因为设计延迟、吞吐量或i/o信号的差异性而降低。当发生这种情况时，测试基准需要手动检查和调整。

    在许多情形下，测试基准比设计还要复杂，使测试基准的改变易受其自身缺陷的影响。根据情况，测试基准故障可能从模块级变化到子系统，或者甚至系统级测试。设计团队通过采用事务或握手接口写测试基准使连续改变的影响限制在局部。

    图1：averaged设计。

    连续等效检查为设计工程师提供了另一种功能验证选项。通过证明具有连续差异的设计之间等效，所有早先的功能验证投入可以在未来rtl的实现中得到利用。连续等效检查确保微架构变换的功能正确性，给设计工程师以信心来进行设计后期的rtl改变。该技术也提供了对副作用的快速检测方法，并确保rtl优化与原始功能意图保持一致。

    连续改变的实例

    一个逻辑设计、模块或整个芯片可以看作由连续状态(或存储器)和组合逻辑构成的机器(machine)。组合逻辑负责计算下一个机器状态，该状态是任一时间点的输入和当前机器状态的函数。根据该逻辑是由moore机器还是由mealy机器构成，机器输出是该时间点的当前状态和/或输入的函数。

    图1中描绘的设计有四个输入值，它输出四个值的平均值及输入值3与平均值的绝对差。通过rtl代码、电路图和状态时序图完全描述了该设计。图1中average4设计表示有一个状态级，即输出上的寄存器。

    改变该设计以连续地读取输入数值就会修改状态和时序。这个连续变换是一个简单连续修正的例子。图2所示为average4设计的连续输入实现，请注意到用于存储输入所加的寄存器、有限状态机(fsm)，以及相应的输出延迟。

    在我们的例子中，图2中average4设计在功能上等效于图1中的average4设计。假设采用相同的输入序列，如果从一致的状态开始，经过一段时间两个设计都产生相同的输出，那么这一对设计被判定为等效。

    在该例子中，简单的检查显示在图1周期n中的采样输出与在图2周期(n*4)+1中的输出匹配。这个例子证明，功能上等效的设计可能实质上存在组合逻辑及存储和访问状态方式上的差异。

    连续变换以改善功率

    随着芯片的日益复杂，需要在性能、面积和功率三者之间进行