[Emulate] Typical Modeling Patterns with TLM API

Published: July 06, 2020 by SingularityKChen (Last updated: July 06, 2020 )

• Categories:
• Emulate 12

• Tags:
• SystemC 15
• TLM 6

• Typical Modeling Patterns with TLM API
  • Modeling Techniques and Guidelines
  • Routers
  • Arbiter
  • Decentralized Routing
  • Pipeline
• Architectural Exploration Using TLM API
  • Hub and Spoke
  • Cross Bar Switch

Typical Modeling Patterns with TLM API¹

Modeling Techniques and Guidelines

• Leverage tlm_fifo to connect incompatible interfaces
  • tlm_fifo provides interfaces in blocking and non-blocking forms
  • Can do blocking puts into the fifo, and non-blocking gets out of it
• Leverage exiting TLM components as much as possible
  • tlm_fifo<T>, tlm_req_rsp_channel<REQ, RSP>, tlm_transport_channel<REQ, RSP>,
• Create generic TLM modules, channels, adapters, etc
• Generic crossbar, pipeline, cache, parallel-to-serial adaptor
• Use deterministic modeling
  • Use two-phase TLM channels
  • Use two-phase primitive channels in SystemC
  • Employ explicit two-phase synchronization scheme

Routers

Route the traffic generated by one master to one of the slaves

1. Receive a request from the master
2. Attempt to find an address range which contains this address
3. Return a suitable protocol error if it is not successful
4. Subtract the base address of the slave from the request
5. Forward the adjusted request to the slave
6. Send the response back to the master

int sc_main( int argc , char **argv )
{ 
  master m("master"); 
  router< ADDRESS_TYPE , REQ, RSP > router("router" , "master.iport.map");
  mem_slave s1("slave_1");
  mem_slave s2("slave_2"); 
  m.initiator_port( router.target_port ); 
  router.r_port( s1.target_port ); 
  router.r_port( s2.target_port ); sc_start( -1 );
  return 0;
}

• RSP constructor must initialize the response to an error state
• REQ must support get_address()

Arbiter

• Arbitrate between two simultaneous requests with timed models
• In a pure PV model, arbitration is a meaningless concept
• Masters
  • Put a request into their transport channel
  • Wait for a corresponding response
• Arbiter
  • Poll all the request FIFOs using nb_get
  • Forward the request to the slave
  • Put the response into the response FIFO in the relevant channel
• Multimap (in stl library)
  • A one to many mapping from priority level to port
  • Can be configured and reconfigured at any time
  • Come with many access functions useful for arbitration
    • Easy to find all ports of the same priority level for use in a prioritized round robin arbitration scheme

Decentralized Routing

• Centralized routing may diverge too far from the implementation
• Decentralized routing
  • All of the slaves monitor all of the requests coming in using peek
  • Pop the request out of the request fifo using get
  • Processes the request and sends a response to the response fifo

Pipeline

• Separate the data transfer into address phase and data phase

void pipelined_master::address_phase()
{
  for( int i = 0; i < 20; i++ ) 
    {
      initiate_write( i , i + 50 );
      initiate_read( i );
    }
}

void pipelined_master::data_phase()
{
  data_phase_request<ADDRESS_TYPE> data_req;
  data_phase_response<DATA_TYPE> data_rsp;
  while( true ) { 
    data_req = outstanding.get();
    data_rsp = data_port->transport( data_req );
  }
}

Architectural Exploration Using TLM API

Hub and Spoke

• All transactions pass through a central hub
• The hub arbitrates between the various requests
• Not efficient in terms of throughput
• Efficient in terms of area and cost
• Only 1 arbiter is needed

Cross Bar Switch

• Being able to make more than one connections at the same time
• No central arbitration
• Every slave has to arbitrate between all the masters
• More expensive and less predictable
• Better throughput

1. IOC5080(5940) System Model Design and Verification, Department of Computer Science, National Chiao-Tung University ↩