在约束相同的情况下,随机种子如果不一样,产生的激励也就不一样了.不知到你介绍的这种技术和我说的情况是否一样.

其实我们很想有这样的技术,根据很多经验的总结，对最容易出现的功能设计错误进行分裂，抽离出一些缺陷模型,当然这需要有比较多的工程设计经验,可能不是工具商的长处。

如果能按照这种缺陷模型去产生激励的化，也许BUG的中的率会更高一些

包含你说的，但正如你说，产生一个这样的缺陷模型不是我们的强项，Infact提供了一些语法，有些模型需要你来写。只不过它很好来完成。具体的你可以参考：

http://www.mentor.com/products/fv/ta/questa_infact/index.cfm

inFact contains the following new technology, not found in any other testbench automation toolset :

1. Rather than write lengthy imperative programs to build a testbench, engineers write brief declarative descriptions, called rule sets, for inFact.
2. inFact can operate on a single rule set to create testbench sequences that test functionality at the module-level, embedded in a subsystem, or embedded in a full system. Other testbench automation toolsets require significant modification (or even a complete rewrite) of a testbench, to be able to use it at multiple levels.
3. inFact can operate on a single rule set to create testbench sequences that can generate different test sequences, depending on the engineer’s current needs, including but not limited to the following – testbench debugging sequences, non-repeating functional coverage sequences, known bug isolation sequences, and lengthy random sequences. Other testbench automation toolsets are limited to a single set of directed test sequences, or at best a re-ordering of random sequences (based on changing a starting seed).