当规格文档写着“SHOULD”时

✦ 01 一个词，可能让团队理解不一致
当规格文档里出现“should”时，设计团队和验证团队未必在理解同一个需求。设计团队可能认为这是一种期望行为，但不是强制要求；验证团队则会追问：这个行为需要测试吗？需要写断言吗？没有发生时算不算失败？

✦ 02 模糊表达，会变成工程成本
在芯片设计中，模糊的词往往并不便宜。一个看似普通的“should”，可能逐步演变成不清晰的RTL行为、不完整的验证计划、遗漏的corner case、争议性的bug判断，甚至在项目后期引发返工。

✦ 03 规格文档的重点不是“写得高级”
好的规格文档不需要复杂或华丽的语言，它真正需要的是明确的设计意图。规格不是给某一个人阅读的说明文字，而是设计、验证、评审、调试和项目决策共同依赖的技术依据。

✦ 04 从“应该响应”到“必须定义清楚”
例如，“The receiver should respond within N cycles.” 看起来合理，但仍然留下了很多解释空间。更清晰的写法应该定义触发条件、时钟边界、响应信号、周期计算方式以及例外条件，例如reset有效时是否排除该要求。

✦ 05 精确语言，让验证目标更明确
当需求写成“The receiver shall assert resp within N rising clock edges after req is sampled high, unless reset_n is low.” 时，设计团队知道该实现什么，验证团队知道该检查什么，评审团队也能更快判断行为是否符合规格。

✦ 06 规格质量，决定后续流程质量
在VLSI项目中，规格文档的模糊性不会自动消失，它只会被传递到RTL、test plan、assertion、coverage和bug triage中。把需求写清楚，不只是文档工作，而是降低设计风险、提升验证效率、减少后期争议的重要工程能力。

课程纵览
行业资讯
职业发展
新闻热点
活动交互