scanchain的基本原理是将设计中所有的触发器连接成一条链，用统一的scan clk驱动，这样可以使用预先设计好的scan pattern用逐bit移入的方法送入芯片中，然后开启capture使能，这样每个触发器的Q端输出会传入他们所驱动的组合电路，scan chain中的下一级出发器D端会捕获这个组合电路的输出，然后capture失效，捕获到的每一级组合电路输出再被移出scan chain，从而在scan chain输出端得到一组结果向量，这组结果向量与工具预先计算好的预期（当然是与输入scan chain的pattern不同的）相比较，从而可以依据比较结果来判断芯片中是否有制造错误。  这里注意两点： * 工具会依据芯片结够生成多种scan patter和输出预期。scan pattern越多，则可以达到的覆盖率就越高。实际中当然是要求尽可能高的scan 覆盖率。 * scanchain的设计是为了侦测制造错误，因此它跟功能验证是完全不同的概念。 通常来讲，工具会帮我们做好一切，而且现在都已经有标准的scanable触发器库，我们只需要看最后的report就好。然而还是会出现一些问题，使得scan coverage达不到要求，这就需要设计者依据report来修改design，以提高scan coverage。 最常见的问题就两种： **某个点不可控**  实际设计中，可能会出现某一级组合逻辑的输入端C并不是来自触发器Q端，这样都会造成组合逻辑的输出端不可控，这样就需要手工插入控制点（用触发器和MUX组成的C’点），以提高scan覆盖率。 **某个点不可观测**  可能某个组合逻辑的输出点O是没有接入到触发器的D端的，这样其输出点就无法被scan chain观测了，那么需要手工插入观测点O’，来提高覆盖率。 注意： * 所有手工加入的观测点和控制点对于原本设计功能而言都是无用的，所以必须用MUX来保证其只在scan模式下有效。 * 加入的观测点可能因为没有实际逻辑作用而在综合时被优化掉，需要在约束上加don't touch说明。