UVM中定义了field automation机制，该机制的思路是将uvm_object类中特别关心的变量，注册到该object类中。后期针对该object类进行的copy/compare/clone等命令，会自动将已注册的变量进行相应操作。在UVM验证中，一种比较常见的操作就是，在scoreboard组件中实现实际数据和期望数据的对比，如图所示。实际和期望的事务包都是uvm_transaction类型的，其包含了多个变量。field automation机制的使用，让数据对比的过程从繁琐的逐个变量中脱离出来。

对于某些协议定义的uvm_transaction事务报文类型，常见的如PCIe协议，其定义了5种报文类型：cfg/memory/IO/msg/cpl，每种报文类型对应着不同的变量；与之相对的，虽然每种报文变量内容不用，但都需要从同一组总线信号上提取（分时复用总线）。图示内容，以从avalon总线种提取PCIe协议memory/cpl两种报文信息为例。

在验证中，我们关注的是所有的总线信号。但是st_hdr信号实际承载的是PCIe报文头标信息；st_data数组信号实际承载的是PCIe报文数据载荷内容。根据UVM验证思想，我们不推荐直接去使用总线信号bit位区间，更推荐将其解析成实际的信息变量。

图示是一种比较常见的操作：因为st_hdr信号承载PCIe memory/cpl报文头标，那就根据st_hdr信号去解析到所有memory/cpl信息。

该transaction，在仿真中使用field automation机制的sprint函数打印得到的信息如图。虽然可以准确正确的解析到此刻总线的数据内容，但并不能体现总线的分时复用特性，看起来更像是总线上同时存在memory/cpl报文头标。这个特性也会生效到field automation的其它函数上。

对于这种现象，更好的解决办法是，在信号解析的过程中，根据解析到的PCIe报文类型，只注册该报文的变量。刚好，UVM field automation机制也支持这种操作，其修改如图所示。

同时修改总线解析报文的函数进行对应的修改：预先解析报文类型，再根据报文类型进行对应的解析过程。

该transaction，在仿真中使用field automation机制的sprint函数打印得到的信息如图，它只会打印匹配的PCIe报文类型的信息。该内容也会生效到field automation的其它函数上。