UVM Transaction Level Modeling Connections

Transaction Level Modeling provides the communication foundation for class-based UVM environments. Components exchange transactions through typed methods rather than direct signal-level coupling. This makes drivers, sequencers, monitors, scoreboards, coverage collectors, register models, agents, environments, and testbenches easier to connect, replace, and reuse. Communication behavior is described through data flow, control flow, timing behavior, and connector roles, giving each connection a clear technical meaning. Data flow defines the movement of transaction items from producer to consumer. Control flow defines the initiator and target relationship. These two directions determine whether a connection is pull-based through get methods or push-based through put methods. Blocking methods allow a transfer to wait until completion, while nonblocking methods return immediately with success or failure. Method families such as put, try_put, can_put, get, try_get, can_get, and peek provide precise choices for transfer control and readiness checking. UVM TLM connectors define the structure of the communication interface. A port starts the call, an imp provides the implementation, and an export routes connections through hierarchy. Connector selection is tied to the required method set, and all methods associated with a selected connector type must be implemented. Connections are usually completed during connect_phase, following control flow from initiator to target. Hierarchical paths must be connected at every level, with exports used to expose target-side access without duplicating implementation objects. Analysis communication supports observation-oriented broadcast. A monitor can publish collected transactions through an analysis port, and that port can connect to zero, one, or many analysis implementations. This one-to-many behavior is unique to analysis connections and makes monitor output highly reusable. Scoreboards, coverage collectors, register models, and other observers can receive the same transaction stream while providing different write() implementations with the same signature. FIFO-based communication adds buffering and decouples transaction production from transaction consumption. uvm_tlm_fifo provides built-in storage, put-side input, get/peek-side output, status methods, and communication method implementations. uvm_tlm_analysis_fifo adapts this buffering model to analysis ports, allowing monitor transactions to be stored before scoreboard processing. With analysis FIFOs, the scoreboard becomes the initiator, explicitly reading from FIFOs, comparing related packets, maintaining local register state, and updating statistics for received, dropped, matched, and mismatched traffic. Bidirectional transport connections combine request and response exchange in one method call. Blocking transport can model time-consuming request-response behavior, while nonblocking transport can report immediate failure when the exchange cannot complete. TLM2 support adds socket-style communication, generic payloads, base protocol concepts, and payload extensions. Generic payloads are especially useful for describing abstract stimulus before a final protocol is selected, while practical multi-language use depends on available simulator support. Catalogue: TLM API Connector Types Data and Control Flow Blocking and Nonblocking Transfers Unidirectional TLM Method Selection Connector and Method Options TLM Connection Implementation Port and Imp Connectors Get Connector Implementation Get Connection Rules Hierarchical TLM Connections Unidirectional TLM Models Analysis Broadcast Connections Broadcast Analysis Example Broadcast Analysis Connection TLM FIFO Component TLM FIFO Example TLM FIFO Connection TLM FIFO Methods Analysis FIFO Buffering Analysis FIFO Scoreboard Analysis FIFO Testbench Connection Scoreboard Using Analysis FIFOs Bidirectional TLM Transport Connection TLM2 Support in UVM