对于在校的学生而言，断言（assertion）可能仅仅是一个新潮的概念，因为学校没有验证。

实际上，断言已经是完完全全地融入到了数字IC验证过程中了。由于断言的存在，DUT在验证工程师眼里不再是一个Design Under Test,更不再是一个black box。

更准确的说，在数字IC验证工程师眼里，我们所验证的设计应该是一个Design Under Explore，等待我们去探索一切的错误、风险以及不合理架构。

考虑上述场景，我们需要黑盒验证由A和B两个子模块集成的设计。假设设计输出比对失败，现象是在valid_i拉高后，valid_o一直保持低。由于这是一个黑盒验证，我们需要花费非常多的时间和精力追溯信号来定位导致问题的根本原因。

但是，如果验证人员已经基于对A子模块和B子模块行为的理解加入(使用SystemVerilog语句“ bind ”）了相应的断言,那么就可以极大地减少调试的时间。

同样是上述的例子：

对于未集成断言验证环境的调试过程：从设计最终的输出端valid_o追溯到输入端valid_i，观察是哪个子模块丢失了这个valid信号。对于上述所示的小型系统设计来说这仍然很简单，但是实际的复杂设计定位过程可能会花费我们好几天的时间，因为可能跨越非常多的模块，甚至团队。

对于集成断言验证环境的调试过程：仅根据子模块A和子模块B中的断言状态就可以快速定位出根本问题所在。如果子模块A的断言失败，我们就无须再查看子模块B的行为是否正确。将画面再拉到一个复杂的系统级设计，你可以想想这些断言对我们有多大的帮助。

即使是一些不存在功能问题的、误报的断言也可能发现设计不那么合理的地方，以帮助我们优化设计架构。