Bidirectional TLM1 port/export

[amal.khailtash]

I am looking for a bidirectional port/export in UVM SystemC implementation.  I could find uvm_*_transport_port/uvm_*_transport_export as well as uvm_*_master_port/uvm_*_master_export/uvm_*_slave_port/uvm_*_slave_export in UVM SystemVerilog implementaion.

Is there any bidirectional implementation in SystemC that might be called something else or should I implement the counter parts of the above, in SystemC?  I can always use multiple single directional port/export, but it would be easier to have one port for ease of connection/implementation.

-- Amal

[Eyck]

You do not specify what you want to achieve therefore it is hard to give any advise.

Ports and exports in SystemC forward and expose a function interface, they act as proxy. To have something bidirectional you need to compose a port and an export. TLM sockets implement something like this so this might be what you are looking for...

[amal.khailtash]

I am working on a TLM model of a design where the design has initiator and target (custom) interfaces.  Some interfaces are unidirectional, just data going from initiator to target, but some are bi-directional.  Think of a memory interface, where a design makes requests (reads/writes) and gets the response back.  In this example, request could be address/and write data and response could be a completion status and a read data if the operation is read.

I was looking at the transport port/export in SV where the initiator sends an atomic request and gets a response back.

[amal.khailtash]

I can see there is a tlm::tlm_transport_channel, but no corresponding uvm::tlm_transport_channel/uvm::tlm_transport_port/uvm::tlm_transport_export/uvm::tlm_transport_imp.  I am looking for an example of such port/channel use.

It seems uvm_tlm_transport_channel is missing from UVM SystemC implementation as well as specified in the RELEASENOTES.  But there is no mention of their SV counter parts uvm_*_transport_*

uvm_blocking_transport_(port|export|imp)
nonblocking_transport_(port|export|imp)
transport_(port|export|imp)

[David Black]

In SystemC, there is no "_imp" because in SystemC, the implementation is called a channel and we simply bind an export to the channel. UVM (SystemVerilog) used the "_imp" approach because when it was invented, SystemVerilog did not have the concept of interface classes like C++.

Checkout my github for more insight on the port/channel relationship in SystemC: https://github.com/dcblack/portexport

Callee is the target module, which is also called a hierarchical channel and represents the implementation.

Two files to examine: README.md and portexport.cpp