在构造芯片验证的激励时，通常DUT接口的激励产生agent会持续发多个请求给DUT，有时候可能是连续不断，没有bubble的，有时候可能会插几个bubble。但总得来说，一般发请求的数量不会少，而且bubble也不会插得特别多个。如果DUT存在多个接口，那么对于很多人来说可能就是在testcase启动后，每个接口都开始发激励，直到testcase结束。
这两种情况看似挺合理正常的，但有时候会遗漏潜在的bug。比如一个接口持续发送请求，那么门控可能会被迫一直打开，无法充分验证门控的正确性。
还有就是当一个口发送的请求数目特别大时，可能会掩盖一些统计类特性的bug，因为数目太大，倒是有些偏差无法看出来。以PMU事件举例来说，假如A事件是B事件的子集，如果TB中检查A的数值一定小于B的数值，在B的值很大情况下，就算A的计数值偏离了，也可能仍然小于B的值，那么TB就无法检查出问题了。
多个激励口同时发激励固然重要，可以使得激励压力更大些。但是芯片在使用过程中，可能只会有其中某些口有激励，因此，随机选择一些口发激励的testcase也必不可少。
稀疏激励的难点在于选择对哪些维度进行稀疏。像请求的个数、请求之间的延迟、参与发送激励的接口数目、请求的属性、错误响应的分布、响应之间的延迟，以及这些维度的交叉等，都是可以细细琢磨的。
