前面描述的TLM port都要求在仿真开始之前与一个export正确地连接。如果port未连接，则会从UVM输出一条错误消息，提示你完成连接。
当我们构建monitor等组件时，需要一个可以不连接或者连接到多个组件的port。这是因为monitor通常是整个验证环境中的passive components，被动地收集数据事务并将其传递给其他组件而不直接影响激励的生成。
UVM中的Analysis ports与常规TLM port类似，但是可以不连接或者连接到任意数量的analysis exports。
从callbacks的角度来看，analysis exports实质上是可以设置不同数量端口连接的callbacks。Analysis ports具有以事务作为参数的函数write（）。每个Analysis ports都有一个被连接的analysis exports列表，当调用Analysis ports的write方法时，就会调用所有analysis exports各自定义的write方法。
write方法是一种函数，因此可以确保Analysis ports写操作不会发生阻塞，并且由于write方法是void函数，在完成写操作后不会返回任何状态。总体效果上，从包含Analysis ports的组件角度来看无需关心任何analysis exports的状态。
//Monitor with an Analysis Port
代码语言：javascript复制class packet_monitor extends uvm_component;
uvm_analysis_port #(simple_packet)analysis_port;
function new(string name, uvm_componentparent);
analysis_port = new("analysis_port",this);
endfunction
virtual task run();
simple_packet p = new();
..// reassemble packet here from lower level protocol
analysis_port.write(p); // write the collectedpacket to the analysis port
endtask
endclass//Component with an Analysis Export
代码语言：javascript复制 class packet_checker extends uvm_component;
uvm_analysis_imp#(simple_packet, packet_checker) analysis_export;
function new(string name, uvm_component parent);
analysis_export= new("analysis_export", this);
endfunction
function void write (simple_packet p);
// checkthe packet here
endfunction
endclass有时，正在通过Analysis Port传递的事务不能被Analysis Export组件立即处理，可能需要将它们存储一段时间才能使用。例如，scoreboard需要将来自DUT输出的实际数据包（actual）与来自reference model的预期数据包（expected）进行比较。在这种情况下，由于来自DUT输出的实际数据包具有延迟，因此需要存储来自reference model的预期数据包。
uvm_tlm_fifo似乎是解决此类问题的好方法，存储数据包直到需要为止。但是，uvm_tlm_fifo没有analysis export，因此无法将其直接连接到monitor的analysis port。UVM中的uvm_tlm_analysis_fifo可以满足此需求， uvm_tlm_analysis_fifo具有analysis export，因此可以将其直接连接到monitor的analysis port。
