Abstract/Concrete Classes

       首先定义一个抽象类（SystemVerilog虚拟类）。抽象类具有纯虚method和properties，这些method和properties定义了用于访问信息的公共接口。method的实现不在抽象类中，而是在被称为具体类的派生类之中。具体类在包装器模块内定义，该模块也实例化BFM。

       DUT Connection  

       由于它是在包装器模块中定义的，具体类的范围（示例中的wb_bus_concr_c）是包装器模块，因此其方法可以访问包装器模块（wb_bus_protocol_module）内定义的任何内容，包括端口，变量，类句柄，函数 ，任务，模块实例等。
       在此图中，在包装器模块内创建了一个BFM实例。具体类的method通过此实例（bmf_instance_name.method_name）通过分层引用访问BFM method。

       【此处需一幅图】

       Two different use models  

       声明抽象类和包装器模块中的具体类之后，有两个使用模型。有一个推荐的使用模型，它遵循抽象/具体的类模式。然后有一个被称为two kingdoms的使用模型，不推荐使用。

       Abstract/concrete class use model

       建议使用此方法，因为它遵循推荐的使用模型，用于将信息从DUT传递到测试平台，这将在有关虚拟接口的文章中详细讨论。在此使用模型中，在定义了具体类的包装器模块内部创建具体类的实际实例。在测试平台内部，通过使用config_db API和配置数据库，使事务传输器（driver、monitor等）内部的基类句柄指向此派生类实例。这里有更多细节、图表和使用BFM的示例。

       Two Kingdoms use model

       这种方法被称为Two Kingdoms。建议不要使用它，因为它不遵循建议的在虚拟接口的文章中详细讨论的使用模型来将信息从DUT传递到测试平台，而是使用factory。此外，它并不严格遵循抽象/具体类模式，在driver、monitor等中使用基类句柄指向具体类实例，而driver和monitor本身则是抽象/具体类。为基类设置factory重载的具体类。在测试平台内部创建一个基类句柄，然后调用factory 的create函数对此句柄进行创建，从而创建了一个具体对象。这里有更多细节，图表和使用BFM的示例。