An Example: A Cache-Memory System

An Example: A Cache-Memory System

The previous section gave a brief overview of classes implemented in OSCI TLM 1.0 library. In this library, several classes and methods are implemented for communication in an efficient and safe manner. In the following, we will use the above classes for a simple design. This design describes a system that contains an RTL cache model with a higher-level memory and a master (like a CPU) in behavioral level. The CPU sends read and write requests to the cache. Since the cache model is in RT level, we have to

convert its signals to adopt them to system level channels for memory and CPU access. The general block diagram of this cache example is shown in Figure 86.80.

Cache Model

The header and the implementation of the cache model are shown in Figure 86.81 and Figure 86.82, respectively. As stated above, this system includes a master (e.g., a CPU) that accesses its memory through a cache.

As shown in Figure 86.81, the interface of the cache with the CPU includes ready, write, read, data, and address signals. Its interface with the memory includes mem_ready, mem_write, mem_read, blk_address, and blk_size signals. blk_address and blk_size signals are used when a miss happens in the cache and the cache needs to read a block from the memory. The cache header file also includes declarations for cache registers and states of the cache controller. Figure 86.82 implements the cache controller using a synthesizable RT level state machine style of coding.

The cache storage is modeled with an array of logic vector (sc_lv type).

The SystemC method cache_op in Figure 86.82 performs the main operation of the cache, and the

state_change method performs state transitions of cache controller.

CPU Model

The header and the implementation of the CPU model are shown in Figure 86.83 and Figure 86.84, respectively. This interface-level model issues read and write requests to cache. The cache model accesses the memory on behalf of the CPU. The CPU model in this system plays the role of a testbench that tests the functionality of the cache, the memory, and their interconnections.

In our implementation, the CPU uses the master_port bidirectional port of basic_initiator_port type. The basic_initiator_port is a class derived from sc_port and it is defined in the examples directory in the OSCI TLM 1.0 library. It has two ports named basic_request and basic_response for byte data transfer between the CPU and the cache transactor (see Figure 86.80 for the role of the transactors).

As shown in Figure 86.84, the master_port uses read and write functions of the basic_initiator_port. Data and address for reading and writing are used as arguments of these functions, e.g., a and d. The run thread defined in the master class performs read and write operations through the master_port channel.

As shown in Figure 86.84, in the CPU model, byte-level TLM function calls are:

request_port and response_port. These two ports are of type block_basic_request and block_basic_response, respectively. These classes are similar to the basic_request and basic_response classes defined in the examples part of the TLM library. They perform block-by-block instead of byte-by-byte data transfer.

Operations for putting and getting data from the memory ports are done in the blocking mode. Therefore, we have to define a thread (instead of a method) for the memory operations. This thread is named run, and it simply waits for a request on its request_port, processes that request by calling the private member function process_request, and puts the result to its response_port. Codes around segments described above are for partitioning of blocks of data to write and read.

Transactors of the Cache Model

As stated earlier, our cache model is developed in RTL, while the other parts of the system have been modeled in a high level of abstraction. The cache model has RTL inputs and outputs, while the other parts of the system use transaction level channels and interfaces as their input/output ports. Therefore, there must be a translator (referred to as transactors) between the cache model and the high-level models on its two sides. One transactor in our design is for connecting the cache model to the CPU, and the other is for connecting the cache model to the memory.

The header and the implementation for the cache-to-master transactor are shown in Figure 86.87 and Figure 86.88, respectively. The header file has the RT level signals that are the same as those defined in the cache model for its CPU interface. These signals include clk, reset, address, data, read, write, and ready signals. In contrast, this transactor has two unidirectional ports named request_port and response_port (recall that a similar port was used in the CPU model for byte-by-byte level read and write).

These ports use nonblocking methods for transferring data. The transactor model uses tlm_non- blocking_get_if and tlm_nonblocking_put_if interfaces for its request_port and response_port, respectively.

The method of this transactor is run, which is sensitive to the positive edge of clk. It is a simple state machine which includes two states named EXECUTE and WAIT. This method decides on its request_port and the ready signal at every positive edge of the clock in the EXECUTE state. Then it sets the proper values to read, write, address, and data signals if the requested operation is WRITE, or reads the proper values from read, write, and address signals if the requested operation is READ. For the READ operation, data is read from the data signal. In the WAIT state, the transactor puts data obtained from the cache to response_port, and waits for it to be transferred.

The header and the implementation for the cache-to-memory transactor are shown in Figure 86.89 and Figure 86.90, respectively.

This transactor is similar to the cache-to-master transactor in that it has several RTL ports that connect it to the cache and two unidirectional ports to convert RTL port data into the high-level memory

On the memory side, TLM ports include a request_port which uses tlm_nonblocking_put_if methods and a response_port which uses and tlm_nonblocking_get_if methods.

Similar to the previous transactor, this transactor has a method named run that is sensitive to the positive edge of clk. This method implements a simple state machine with two states named REQUEST and RESPONSE. This method reads mem_read and mem_write signals from its cache side signals and makes the proper requests for sending the data obtained from the cache to the memory via its request_port. It then obtains memory response via its response_port and asserts the mem_ready signal.

Connecting the Models in main.cpp

The above sections described individual components of Figure 86.80. These models must be connected together to generate a complete system. This is done in the main.cpp file shown in Figure 86.91. There are two channels, cache_mem_chan (of type tlm_req_rsp_channel) and cache_mas_chan (of type tlm_transport_channel) in this code. These channels connect the CacheMasterTrans (an instance of cache-to-master transactor) and CacheMemTrans (an instance of cache-to-memory transactor) to the CPU and memory, respectively.

Our Coverage of TLM

In this section, TLM techniques were discussed. These techniques are useful for efficient modeling of communication parts in a system. When size and complexity of a system grows, communications between various modules in a system can be a bottleneck for system performance. Therefore, having well-defined methods to model and simulate system communications helps designers develop more efficient designs. Sections in this chapter discussed various steps in ESL. It began with high-level modeling of a design using UML 2.0. Then, developing a high-level early prototype of a system was discussed in the section on C/C++. After developing an early prototype and partitioning a system, the hardware partitions can be modeled in a hardware-based and high-level language. Therefore, SystemC was described in the section after C/C++. The last section of this chapter discussed TLM that has several predefined efficient ways to model communication in a system.