uvmc 2.3.1 源代码，用来 SC 和 SV 的混合仿真

-------------------------------------------------------------------------------- Title: Converters -------------------------------------------------------------------------------- This chapter shows how to write converters for your transactions. Converters facilitate data exchange between components residing in different languages. If components were written in a common language, you could guarantee they exchanged compatible data simply by requiring they use the same transaction type. Such components are ~strongly typed~. Any mismatch in type would be caught by the compiler. Now let's say two components were developed such that each agreed more or less on the content of the transaction, but this time their transaction definitions were of different types. This condition always the case between components written in two different languages--they cannot possibly share a common transaction definition. To get such components talking to each other requires an adapter, or converter, that translates between the transaction types defined in each language. Topic: Got Transactions? ------------------------ UVM Connect imposes very few requirements on the transaction types being conveyed between TLM models in SV and SC, a critical requirement for enabling reuse of existing IP. The more restrictions imposed on the transaction type, the more difficult it will be to reuse the models that use them. - No base classes required. It is not required that a transaction inherit from any base class to facilitate its conversion--in either SV or SC. The converter is ultimately responsible for all aspects of packing and unpacking the transaction object, and it can be implemented separately from the transaction proper. - No factory registration required. It is not required that the transaction register with a factory--via a ~`uvm_object_utils~ macro inside the transaction definition or by any other means. - It is not required that the transaction provide conversion methods. The default converter used in SV will expect the transaction type to implement the UVM pack/unpack API, but you can specify a different converter for each or every UVMC connection you make. Your converter class may opt to do the conversion directly, or it can delegate to any other entity capable of performing the operation. - It is not required that the members (properties) of the transaction classes in both languages be of equal number, equivalent type, and declaration order. The converter can adapt disparate transaction definitions at the same time it serializes the data. The following are valid and compatible UVM Connect transaction definitions, assuming a properly coded converter: |SV SC |class C; struct C { | cmd_t cmd; long addr; | shortint unsigned address; vector<char> data; | int payload[MAX_LEN]; bool write; |endclass }; - In UVM SV, it is required that the transaction class constructor not define any required arguments. It may have arguments, but they all must have default values. The first constructor argument must be ~string name=""~. Topic: Do You Need a Converter? ------------------------------- If your models exchange non-extended TLM Generic Payload transactions, you do not need to concern yourself with transaction or converter definition. TLM GP definitions and converters are provided by the libraries, so you may skip this section. Topic: Easy When You Need Them ------------------------------ To enable non-TLM GP object transfer across the SV-SC boundary, you must define converters in both languages; UVMC makes this an easy process. Defining a converter involves implementing two functions--~do_pack~ and ~do_unpack~--either inside your transaction definition or in a separate converter class. Although the means of conversion are similar between SV and SC, differences in these languages capabilities cause differences in conversion. The following sections describe several options available to you for writing converters in SV and SC. -------------------------------------------------------------------------------- Group: SV Conversion options -------------------------------------------------------------------------------- Here, we enumerate three different ways to define conversion functionality for your transaction type in SV. We illustrate each of these options using the following packet definition. SV Transaction: | class packet extends uvm_sequence_item; | | typedef enum { WRITE, READ, NOOP } cmd_t; | | `uvm_object_utils(packet) | | rand cmd_t cmd; | rand int addr; | rand byte data[$]; | ... | | endclass Topic: In-Transaction --------------------- This approach defines the conversion algorithm in transaction class itself. (see UVMC_Converters_SV_InTrans.png) A transaction in UVM is derives from ~uvm_sequence_item~, which defines the ~do_pack~ and ~do_unpack~ virtual methods for users to implement the conversion functionality. This option is the recommended option for SV-based transactions. To use this approach, you declare and define overrides for the virtual ~do_pack~ and ~do_unpack~ methods in your transaction class. | virtual function void do_pack (uvmc_packer packer); | virtual function void do_unpack (uvmc_packer packer); Most transactions in SV should be defined this way, as it is prescribed by UVM and it works with UVM Connect's SV default converter. See <Default Converters> for details. The following SV packet definition implements the ~do_pack~ and ~do_unpack~ methods using a set of small utility macros included in the UVM. These macros implement the same packing functionality as using the ~packer~ API or ~`uvm_field~ macros, but are more efficient. See <UVMC Converter Example - SV In-Transaction> for a complete example of using this approach. | class packet extends uvm_sequence_item; | | typedef enum { WRITE, READ, NOOP } cmd_t; | | `uvm_object_utils(packet) | | rand cmd_t cmd; | rand int addr; | rand byte data[$]; | | constraint C_data_size { data.size inside {[1:16]}; } | | function new(string name=""); | super.new(name); | endfunction | | virtual function void do_pack(uvm_packer packer); | super.do_pack(packer); | `uvm_pack_enum(cmd) | `uvm_pack_int(addr) | `uvm_pack_queue(data) | endfunction | | virtual function void do_unpack(uvm_packer packer); | super.do_unpack(packer); | `uvm_unpack_enum(cmd,cmd_t) | `uvm_unpack_int(addr) | `uvm_unpack_queue(data) | endfunction | | ... | | endclass When implementing the ~do_pack~ and ~do_unpack~ methods, you may call various methods of the provided ~packer~ object, or you can use a set of small, more efficient convenience macros, also provided in UVM. The following packs an ~addr~ field using each approach. Our example above uses the small-macro approach. | virtual function void do_pack(uvm_packer packer); | | `uvm_pack_int(addr) -or- | packer.pack_field(addr,$bits(addr)); //more overhead | | endfunction Topic: Converter Class ---------------------- For transactions not extending ~uvm_sequence_item~, you can define a separate converter class extending ~uvmc_converter #(T)~. You then specify this converter type when calling <The Connect Function>. (see UVMC_Converters_SV_UserDefined.png) The following SV packet definition implements the ~do_pack~ and ~do_pack~ methods required of any custom converter. The same small macros used in the <In-Transaction> approach can be used in this approach. See <UVMC Converter Example - SV Converter Class> for a complete example. | class convert_packet extends uvmc_converter #(packet); | | static function void do_pack(packet t, uvm_packer packer); | `uvm_pack_enum(t.cmd) | `uvm_pack_int(t.addr) | `uvm_pack_queue(t.data) | endfunction | | static function void do_unpack(packet t, uvm_packer packer); | `