Transactor vs CPU in SoC Verification

By Guruprasadh PV, BlueBerry Semiconductors

ABSTRACT

The objective of this paper is to explain the advantages of using CPU at SoC level instead of transactor. This paper puts forward few examples for understanding the differences.

INTRODUCTION

This paper gives brief overview of SoC verification using transactor and CPU. Transactors cannot always replace the functionality of CPU. It helps in reproducing some of the scenario’s like read/ write or different data lengths etc. but certain attributes of CPU behavior cannot be replicated. A simple read and write test using CPU also depends on some previous transactions (error response /interrupt etc) . This is primarily because of pipeline Architecture and cacheable attributes that can be configured.

COMPARISON

As briefed in the above paragraph, read/write test with CPU depends on many factors. This can be best understood when cache allocation is set to Write allocate.

a. Let us consider AXI4 protocol to understand this when CPU register is configured with write allocate

When this combination is used, a write to cacheable address, results in cacheable length of data is read from memory (executing a store instruction on the processor might cause a burst read to occur. There is a line fill to obtain the data for the cache line, before the write is performed) and stored in cache along the with the data specified in the instruction (this happens on cache miss). This can potentially result in decode or slave error if this read access results in access to reserved memory (this can occur when the cacheable address is very close to reserved address). This behavior cannot be observed when transactor is used

b. Toggle coverage of AXI signals

Transactors are also used for toggle coverage and functional coverage of AXI signals ( e.g memory) but these two can be achieved using by writing specific instructions. This is more true in case of toggle coverage. There is a relationship between the instructions and axi signals. Once this is understood, it is easier to understand the data flow and toggle coverage of axi ports.

To explain the about the relationship, let use consider WSTRB signal as an example. Below is a snapshot where wstrb was toggled using instruction set. Similarly, most of AXI port signals can be covered using Instruction set. This would not be covered in this paper as this requires explanation in detail

c. Early BRESPONSE

System behavior/performance changes, when NIC is configured for early Bresponse

We can configure ARM to give non-cacheable bufferable transfer and non-cacheable

non bufferable transfer. We can notice changes in the performance of SoC when these two features are tested separately.

e.g when you have block A, Block B and Block C whose registers need to be configured, when ARM is writing in to Block C, NIC would be writing in to Block B. Essentially what ARM sees as done is actually in the process of being completed

System behavior is very important when some features are tested. NIC would generate interrupt when there is error response from end slave

Early Bresponse is important feature which is used for analyzing the overall performance of the system (SoC). Performance of SoC can be best analyzed with the usage of CPU

d. System Hang

CPU stops when there is no response for one of the previous transactions. Consider the example when CPU wants to read the instruction code from memory. When CPU did not receive response for one of instruction reads, CPU continues to execute the instruction that is already fetched but stops when there is no instruction data to execute. Transactor would also stop (generic statement) when there is no response to read as it does not deal with instruction execution. Though it looks like transactor is better option in this case but few instructions that CPU executed before CPU hangs, can result in different SoC behavior

e. Miscellaneous

When External booting is used, bit2 of ARPROT toggles when there is instruction read, as we do not write instruction, bit 2 in AWPROT cannot be expected to toggle

Of late I have seen Engineer’s verifying blocks at SoC level using transactors (e.g verifying peripheral by replacing AXI to APB bridge with transactor) which I would say is not the best practice. This will not help in identifying CDC bugs. In SoC most of the bugs could be in CDC, wrong routing of address from interconnect and wrong interrupt connection.

The other observation is about the negative scenario’s in AXI. Since Most of the CPU’s having AXI interface would be AXI protocol compliant and in most cases, so would be the slave or peripheral ip. Therefore, visualizing negative scenario would not be that much effective.

CONCLUSION

Transactor might be useful for verifying connectivity by performing data transactions but it may not be useful to verify all the scenario’s. In case of SoC with multi cluster processor with L3 cache, it would be best to check with CPU as snoop attributes that gets involved