这些方法的原型：

int first(string seeking，int ignore = 0)where seek是要搜索的字符串，ignore是字符串开始处(或结束时，对于last())的字符数，应该跳过 通过搜索。 它们的结果是找到的字符串在原始字符串中最左边的字符的位置。执行成功是快速反馈

这种方法给我们即时反馈小的执行错误，否则可能很难找到。 每个单元测试运行得非常快，它可以给出任何运行时间在20秒以内的代码改变时的成功或失败信息，即使是在三种主流的模拟器上运行。有了这个能力，在所有支持的平台上测试每一个新的变化只需要不到一杯咖啡的功夫，我们因此能高度的保持代码库在任何时候都能正常工作。SVUnit的简单明了的报告机制将执行错误迅速锁定到单个测试用例。API库的连续完整性检查

单元测试还为我们提供了面向用户的API是否方便智能的预判，因为我们不得不在实现之前使用该API编写测试代码。糟糕的设计因此会被迅速的凸显出来。例如，我们之前尝试在一个函数中包含多个可选参数(比如参数具有默认值)。错误很快凸显出来，这对于用户来说是极易出错的，因为它很容易提供一个值到错误的可选参数，并因此导致令人惊讶的结果。单元测试组成的文档池

最后，不断增加的测试组件持续提供各种示例函数的有用信息，这样的一个好处就是每个示例的测试结果都是被单独记录的。

B、文档

使用自动文档生成器(例如Doxygen或NaturalDocs)来记录这些包已经变得很流行了。它们具有显而易见的重要优点，即代码有改变时文档将自动更新。然而，我们选择了减少这种趋势，并恢复为传统的手动生成的文档。 这个似乎倒退的步骤是在仔细思考后才采取的。 从代码及其注释生成的文档往往专注于单个代码片段的属性，直到功能级别。但是我们认为人们更有可能对包的总体理论感兴趣：其组件之间的关系， 以及它作为一个整体所遵循的任何指导原则。 我们相信这些信息更好地捕捉在人工手写的材料中。

当代码库快速变化时，会发现自动生成的文档的巨大优势，因为必须不断审查层次结构中的类之间的复杂关系。 但是对于像svlib这样的包的用户面向行为应该被做的非常稳定，因此这个优势不太明显。

十一、性能

虽然svlib提供了一些SystemVerilog难以实现的功能性接口，但是如果其性能不可接受地慢，那么该方便性将是无用的。我们已经测量了所选svlib功能的性能成本，我们认为这是可以接受的，因为诸如文件访问和操作大字符串的性能耗竭操作很可能只会很少使用。

十二、未来的工作

我们有一个广泛的未来工作的“购物清单”，我们希望在资源允许的情况下添加，以及如果对它们有任何需求。其中我们应该提到：完全支持MicrosoftWindows®平台

支持逗号分隔值(CSV)表格数据文件

支持对数据库的SQL访问

将已打开的C文件句柄与Verilog文件标识符相关联。通过这种机制，将提供广泛的有趣的新功能，包括对临时文件的支持，以及通过TCP / IP套接字和其他网络机制的通信。

如果可以在SystemVerilog和诸如Python之类的脚本语言之间建立紧密的连接，将会产生大量激动人心的可能性。这个想法已经通过PyHVL项目以略微不同的方式进行了探索，我们几乎没有开始考虑这一领域可能的相互作用。

十三、小结

初始版本可在发布时下载，可通过访问www.verilab.com/resources下的svlib链接找到。

我们认为这是一个beta质量版本：它有一个完整的功能集，我们自己已经在大量使用它，但它还没有在项目工作中的大量使用，因此可能不够成熟。因此，我们欢迎潜在用户的反馈，我们希望使用DVCon来收集用户对这样的库的反馈。

如果这项倡议得到热烈欢迎，我们将开始寻求办法使更广泛的社会支持它并推动它。作者欢迎任何反馈，包括svlib的技术内容及其在实践中的实用性。