SoC Cache Testing Method for Design for Testability

Abstract

The present invention discloses a SoC cache testing method for design for testability. This method isolates the L1 Cache and configures the instruction area to be cacheable to reduce unnecessary access to the L2 Cache. At the same time, it defines a test space of a preset size to ensure coverage of all potential cache areas. Before the test starts, keep the L2 Cache closed. When the test starts, enable the L2 Cache and, by configuring the L2 Cache controller, ensure that the test instructions are fixed in the L2 Cache. The MBIST testing algorithm is used to comprehensively test the test space to detect the data integrity and functionality of the L2 Cache. Through the above measures, the present invention can effectively detect possible problems in the SoC cache, improve the yield rate of the chip and reduce the production cost.

Description

Technical Field

[0001] The present invention relates to a method for testing a cache, and more particularly to a method for testing an SoC cache for design for testability, belonging to the technical field of integrated circuit testing. Background Art

[0002] With the continuous progress of integrated circuit technology, the integration degree of chips is getting higher and higher. The wide application of advanced structures such as Fin-FET in IC design makes the test cost account for a quite large proportion in the whole chip design cycle, about 20-30%. Traditional functional testing is no longer sufficient to meet the complexity and quality requirements of modern chip design. Therefore, the concept of design for testability (DFT) emerged as the times require and was closely integrated with the design process at the early stage of chip design. Design for testability includes two parts: functional testing and manufacturing testing. Functional testing is mainly used to verify the logical behavior of the circuit and find possible errors in the design, while manufacturing testing focuses on detecting possible defects in the manufacturing process, such as open circuits, short circuits, etc.

[0003] In the DFT test stage of the chip, it is crucial to ensure the integrity of the cache. Because if the problems of the cache are not fully detected, defective chips may flow into the market, causing economic losses to the manufacturer. To solve this problem, in addition to the existing MBI ST (Memory Built-In Self-Test) technology, testing the cache by software has become an effective technical means. Software testing can detect the performance and stability of the cache under various working conditions by simulating different usage scenarios and data patterns, so as to identify and repair potential problems in advance. In the current design of system-on-chip (SoC), the usage ratio of external caches is increasing day by day. This makes it crucial to develop an effective method for testing external caches of SoC to improve the yield rate of chips and reduce production costs.

[0004] In the Chinese invention patent with the patent number ZL 201880098721.7, a method for testing operational adaptability integrated circuits is disclosed. This method allows the performance of the integrated circuit to be adjusted by configuring the values of operational parameters. The specific method includes: setting the integrated circuit to a test mode, which is different from the normal operating mode of the circuit; in the test mode, inputting a test signal composed of specific test values into one or more adaptability processing paths of the circuit. These processing paths contain processing logic and buffer circuits, which generate output values based on the input values and can adjust the efficiency according to the configuration of the operational parameters. By collecting the test output values generated by these processing paths, a set of test output signals is formed. Then, by checking these test output signals and forming test results, and finally using these test results to select and set the values of the operational parameters of the integrated circuit. This method helps to improve the test efficiency and accuracy of the integrated circuit. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method for testing the external cache of an SoC for design for testability.

[0006] To achieve the above object, the present invention adopts the following technical methods:

[0007] An SoC cache test method for design for testability includes the following steps:

[0008] (1) Isolate the L1Cache in the SoC; among them, configure the attribute of the instruction area to be cacheable so that instructions are stored in the L1 instruction Cache, and set other address areas to be non-cacheable to reduce unnecessary access to the L2 Cache;

[0009] (2) Define a test space with a preset size and configure it to be cacheable for storing and accessing test data;

[0010] (3) Before the test starts, keep the L2 Cache in the off state to ensure that only the preset test instructions will pass through the L2 Cache during the test;

[0011] (4) At the start of the test, enable the L2 Cache and, by configuring the L2 Cache controller, ensure that the preset test instructions are fixed in the L2 Cache;

[0012] (5) Use the MB IST test algorithm to test the entire test space to detect the data integrity and functionality of the L2Cache.

[0013] Preferably, in step (2), according to the hierarchical structure of the cache in the SoC and the relationship between different cache levels, the size of the test space is determined to ensure that all potential cache areas can be covered.

[0014] Preferably, when the test target is the L2 Cache, if there is an inclusive relationship between the L1 Cache and the L2 Cache, the size of the test space is at least twice the size of the L2 Cache; if there is an exclusive relationship between the L1 Cache and the L2 Cache, the size of the test space is at least the size of the L1 Cache plus twice the size of the L2 Cache.

[0015] Preferably, when the test target is the L3 Cache, if there is an inclusive relationship between the L1 Cache, the L2 Cache, and the L3 Cache, the size of the test space is at least twice the size of the L3 Cache; if there is an exclusive relationship between the L1 Cache, the L2 Cache, and the L3 Cache, the size of the test space is at least the size of the L1 Cache plus the size of the L2 Cache, plus twice the size of the L3 Cache.

[0016] Preferably, in step (4), the preset instructions fixed in the L2 Cache include enabling the L2 Cache, writing test data to specific memory addresses, reading data from these addresses, and comparing the read data with the expected values.

[0017] Preferably, in step (4), different test patterns are written in the test space, and then these data are read and compared to verify their integrity and consistency; among them, the number of test instructions does not exceed 10.

[0018] Preferably, the size of the test pattern is determined by two parameters M and N, where M represents the number of groups of the test pattern and N represents the number of types of data.

[0019] Preferably, in step (5), the AXI bus first performs a 1B INCR 1 transfer to fill the extra bytes required for alignment, and then starts the remaining 1B transfers from the next aligned address to complete the writing of 2B data.

[0020] Preferably, in step (5), a pseudo-random replacement strategy is adopted to implement the replacement of cache lines; in the pseudo-random replacement strategy, when a cache line needs to be replaced, a cache line is randomly selected from all available cache lines for replacement.

[0021] Preferably, in step (5), a cyclic rotation victim selection strategy is adopted to implement the replacement of cache lines. In the cyclic rotation victim selection strategy, a pointer is maintained. Each time a cache miss occurs, the pointer moves to the next cache line in sequence. When the pointer reaches the end of the cache line array, it loops back to the beginning of the cache line array, forming a cycle.

[0022] Compared with the prior art, the SoC cache test method provided by the embodiments of the present invention effectively reduces unnecessary access to the L2 Cache by isolating the L1 Cache and configuring the instruction area as cacheable, making the cache test more focused. At the same time, by defining a test space of a preset size and flexibly determining the size of the test space according to the hierarchical structure of the cache in the SoC and the relationship between different cache layers, it is ensured that all potential cache areas can be comprehensively covered. In addition, by adopting the MB IST test algorithm and software simulation technology, various usage scenarios and data patterns can be simulated to detect the performance and stability of the cache under different working conditions. Using the present invention helps to identify and fix potential problems of the SoC external cache in advance, effectively improving the chip yield rate and reducing the production cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic connection diagram between an MB IST controller and a cache controller in the prior art;

[0024] Figure 2 It is a schematic diagram of the SoC architecture with an external L2 Cache in the embodiments of the present invention;

[0025] Figure 3 It is a schematic diagram of the SoC architecture with an external L3 Cache in the embodiments of the present invention;

[0026] Figure 4 It is an example diagram of the cache structure in the embodiments of the present invention;

[0027] Figure 5 It is a schematic diagram of a cache system with a 32-bit physical address in the embodiments of the present invention;

[0028] Figure 6 It is a flowchart of the cache test process provided by the embodiments of the present invention;

[0029] Figure 7 It is a schematic diagram of the read and write states of data in the cache structure during six rounds of tests conducted in the embodiments of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0030] The technical content of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0031] Figure 1 In the prior art, it is a schematic diagram of the connection between a typical MBI ST controller and a cache controller. This figure shows a configuration method for performing MBI ST testing on a cache controller without using the data banking technology. In this configuration, the MBI ST controller is responsible for generating test vectors and detecting memory responses to detect various faults in the cache. The scheduling unit controller is responsible for coordinating the entire MBI ST test process. The Cache controller manages all operations of the cache, including data reading and writing and the implementation of cache policies. In addition, Dataparity (data parity check) RAMs are used to store the parity check information of the data to ensure data integrity. Data (data) RAMs are random access memories used for data storage in the cache, while Tag (tag) RAMs store the tag information of the cache data, which is crucial for the rapid retrieval and identification of data.

[0032] As is well known, in a system-on-chip (SoC), in order to improve the performance and response speed of a processor (CPU), a multi-level cache system is usually integrated, such as L1 Cache, L2 Cache, and L3 Cache, etc. The most basic configuration includes at least a first-level cache, that is, L1 Cache, which is directly integrated inside the core of the CPU. For a multi-core processor system, each CPU core has its own L1 Cache, which can ensure that each core can quickly access its own data and instructions, reducing competition and latency between cores.

[0033] L1 Cache is usually further divided into L1 data cache (L1 Data Cache) and L1 instruction cache (L1 Instruction Cache). Among them, the data cache is used to store the recently accessed data, while the instruction cache is used to store the recently executed instructions. This separated design helps to improve the efficiency of the cache because data and instructions often have different access patterns and locality characteristics. The independence of the data cache and the instruction cache allows the CPU to optimize them specifically. For example, the data cache may implement a more complex prefetching strategy, while the instruction cache may adopt a more efficient branch prediction technology.

[0034] In some SoC designs, in addition to the L1 Cache within each core, there may also be a shared L2 Cache. The capacity of the L2 Cache is usually larger than that of the L1 Cache. It provides a larger shared cache space for multiple cores to reduce the need to access the system main memory. In some SoC architectures, the L2 Cache may be private to each CPU core, while in other architectures, it may be shared by multiple cores. The design of the shared L2 Cache helps improve data consistency and availability among cores, while also increasing the complexity of the cache system.

[0035] However, not all SoC architectures integrate an L2 Cache. In some designs, the L2 Cache can be omitted and replaced with an external cache solution as shown in Figure 2 . In this case, the SoC needs to communicate with the external L2 Cache through a high-speed interface (such as the AMBA AXI bus). The external L2 Cache can provide a larger cache capacity and higher flexibility, but it may also increase access latency and system cost.

[0036] As shown in Figure 3 , in some SoC designs with an L2 Cache, there may be no L3 Cache. In this case, if a larger cache capacity or a more complex cache hierarchy is needed, an external L3 Cache needs to be added. The L3 Cache is usually a larger shared cache that serves all CPU cores in the entire SoC. The introduction of the L3 Cache further increases the cache capacity and system complexity, but at the same time it also increases the possibility of data reuse, thus reducing the access frequency to the main memory.

[0037] In an embodiment of the present invention, the cache is organized into multiple levels, where each level consists of multiple cache lines. A cache line is the smallest unit in the cache for storing data, and the cache line size determines the amount of data that each cache line can store. The entire cache capacity is jointly determined by the sizes and quantities of all cache lines. The cache is usually divided into multiple "ways", and each "way" consists of multiple "banks". Here, a bank refers to a cache block composed of multiple cache lines, which is used to achieve parallel access and data storage in the cache.

[0038] In a cache structure, cache lines are addressed by an index, and each index corresponds to a specific cache line position. For example, Addr0 represents the 0th cache line, and Addr4 represents the 4th cache line. The addressing method of the cache is numbered in units of cache lines, so that data in the cache can be quickly located.

[0039] In Figure 4 the illustrated embodiment, each rectangle represents a cache line, and its length represents the size of the cache line. Rectangles of the same color belong to the same "way", and the vertical columns represent the same "bank". In this organization, X represents the number of "banks" in the cache RAMs, Y represents the number of "ways", and N represents the number of cache lines in one "way". This structured design enables the cache to efficiently store and retrieve data, and also supports complex cache coherence protocols.

[0040] As Figure 5 shown, in a cache system with a 32-bit physical address, if the cache line size is set to 32 bytes (B), and the entire cache capacity is 128 KB, and an 8-way set-associative and 4-bank cache configuration is adopted, we can define the variables in the cache structure based on these parameters. Specifically, X represents the number of banks in each Cache RAMs, where X is equal to 4; Y represents the number of ways of set-associativity, where Y is equal to 8; and N represents the number of cache lines in each way. By calculation, N is equal to 128 KB divided by (the number of banks multiplied by the cache line size), that is, 128 KB / (4 * 32B) = 512. Such a configuration allows the cache system to store and access data in an efficient manner, while ensuring that the organizational structure of the cache can meet specific performance requirements. In Figure 5 this, these parameters will determine the physical layout and addressing method of the cache, where the size of each cache line, the number of ways, and the number of banks will directly affect the overall performance and capacity of the cache.

[0041] From Figure 1It can be seen that the existing MB IST technology is mainly used to test the RAMs in the cache to detect various possible faults. In a chip with a two-level cache architecture including L1 Cache and L2 Cache, the L1 Cache is close to the processor core, and the L2 Cache is located between the L1 Cache and the main memory. A key difference between the L2 Cache and the L1 Cache is that the L2 Cache is usually a shared resource for storing data and instructions, while the L1 Cache stores data and instructions separately. Although the MB IST technology is very effective in detecting faults in the RAMs in the cache, its test configuration cannot fully simulate the interaction between the L1 Cache and other components through interfaces such as the AXI bus in an actual chip. This lack of simulation results in MBIST being unable to comprehensively cover all functional tests of the L1 Cache and L2 Cache when they work simultaneously, especially the problem of Cache Line data errors that may occur when they operate in cooperation, which is a challenge that the current MBIST technology has not yet solved.

[0042] To make up for the deficiencies of the current MB IST technology, the embodiments of the present invention propose an SoC cache test method for design for testability. This test method aims to comprehensively test the entire L2 Cache space by software simulating the existing MB IST technology.

[0043] Specifically, the L1 Cache needs to be isolated first. This is because the L1 Cache is divided into an instruction cache and a data cache, which will interfere with the test of the L2 Cache. To achieve this, only the attributes of the instruction area are configured as cacheable (Cacheable), which means that instructions can be stored in the L1 Cache, while other address areas are set as non-cacheable (Non-Cacheable) to reduce unnecessary access to the L2 Cache.

[0044] Next, a test space of a preset size is defined and configured as cacheable for storing and accessing test data. It should be noted that this test space is usually implemented by RAMs (random access memories). Such a design choice aims to provide a controllable and reliable test environment for accurately evaluating the performance and reliability of the L2 Cache. The preset size of the test space is carefully designed to be at least able to cover the 128K size of the L2 Cache Memory. This is to ensure that the test can reach all potential areas of the cache and thus discover problems that may exist in different cache areas.

[0045] When determining the size of the test space, it is first necessary to understand the cache hierarchy in the SoC and the relationships between different cache levels. As previously mentioned, the SoC can include multiple levels of caches, such as L1, L2, and L3 Cache, and the relationships between them can be inclusive or exclusive. These relationships are crucial for determining the size of the test space.

[0046] When the test target is the L2 Cache, if the relationship between the L1 Cache and the L2 Cache is inclusive, it means that the L2 Cache contains all the data of the L1 Cache. Therefore, the size of the test space should be at least twice the size of the L2 Cache. This ensures that during the test, the data in the L2 Cache can be fully replaced, thus detecting possible cache line replacement issues. If the relationship between the L1 Cache and the L2 Cache is exclusive, then the size of the test space should be at least the size of the L1 Cache plus twice the size of the L2 Cache (i.e., L1Cache Size + L2 Cache Size * 2). This configuration allows the test to cover the data exchange and cache coherence between the L1 Cache and the L2 Cache.

[0047] Similarly, if the test target is the L3 Cache and the relationships between the L1 Cache, the L2 Cache, and the L3 Cache are inclusive, then the size of the test space should be at least twice the size of the L3 Cache. This is to ensure that all data lines in the L3 Cache can be tested. If the relationships between these cache levels are exclusive, then the size of the test space should be at least the size of the L1 Cache plus the size of the L2 Cache, plus twice the size of the L3 Cache (i.e., L1Cache Size + L2Cache Size + L3 Cache Size * 2). Such a test space configuration can ensure that the test can cover all levels of caches and verify the data flow and coherence between them.

[0048] Before conducting software testing on the L2 Cache, it is first necessary to isolate the L1 Cache because the L1 Cache is divided into an instruction cache and a data cache, which may interfere with the testing of the L2 Cache. To achieve isolation, only the attributes of the instruction area are configured as cacheable (Cacheable), which means that instructions can be stored in the L1 instruction cache, while other address areas are set as non-cacheable (Non-Cacheable) to reduce unnecessary access to the L2 Cache.

[0049] Before the test starts, the L2 Cache is kept in the off state. This is done to ensure that only a very small number of instructions pass through the L2 Cache during the test, thereby reducing the interference of instructions on the L2 Cache and providing a cleaner test environment. This step is crucial as it allows the test engineer to focus on data testing without being potentially affected by the instruction stream.

[0050] Once the test starts, the L2 Cache is enabled, and by configuring the L2 Cache controller, it is ensured that instructions are pinned in the L2 Cache. Such a design minimizes the impact of test instructions on the L2 Cache, thus leaving more cache space for data testing. The test instructions are carefully designed and limited to no more than 10 in number to ensure that the cache lines they occupy are minimized.

[0051] In this way, the test data can fill most of the space in the L2 Cache, while the cache lines occupied by the test instructions are limited to a minimum. This means that even during the test, the L2 Cache can provide sufficient storage space for data testing, thereby ensuring the comprehensiveness and accuracy of the test.

[0052] The purpose of pinning instructions in the L2 Cache is to precisely control and observe the behavior of the cache system, especially in the test environment. This practice allows the test engineer to specifically monitor and analyze the data flow and changes from the data bus of the L1 Cache to the L2 Cache without being potentially interfered by the instruction bus of the L1 Cache to the L2 Cache. Specifically, the instructions pinned in the L2 Cache include enabling the L2 Cache, writing test data to specific memory addresses, reading data from these addresses, and comparing the read data with the expected values.

[0053] Finally, the entire test space is tested using the MBI ST test algorithm. This can utilize the mature MBI ST test technology to detect the data integrity and functionality of the L2 Cache. By this method, the data access patterns in actual applications can be simulated, where the number of data read and write operations is much larger than the number of control instructions, thereby ensuring the performance and stability of the L2 Cache under various conditions.

[0054] Through the above test method, the L2 Cache can be comprehensively tested. In addition, using this test method can also verify the cache replacement policy, coherence protocol, and cache behavior in a multi-core environment. Moreover, it can simulate different workloads and access patterns to ensure the performance and stability of the L2 Cache under various conditions.

[0055] When conducting software testing on the L2 Cache, the core of the test strategy lies in ensuring that the impact of test instructions on the cache is minimized, so as to leave as much space as possible for data testing. To this end, the test code is designed with an efficient traversal mechanism, whose purpose is to write different test patterns in the test space, and then read and compare these data to verify their integrity and consistency. During this process, the number of test instructions is strictly controlled (in principle, no more than 10), to ensure that they only occupy a very small number of L2 cache lines.

[0056] Regarding the test patterns adopted in the embodiments of the present invention, the specific description is as follows:

[0057] When designing the test patterns, the relevant attributes of two key modules need to be considered: the AXI interface reserved by the CPU and the configuration of the Cache. The attributes of the AXI Master interface on the CPU side include the supported bus width (AxSIZE), bus transfer length (AxLEN), and bus transfer type (AxBurst). These parameters determine the data transfer capabilities. For example, the widths supported by AxSIZE are 1B, 2B, 4B, 8B, the transfer lengths supported by AxLEN are from 1 to 16B, and the types supported by AxBurst include INCR (increment) and WRAP (wrap).

[0058] As an AXI Slave, the parameters of the Cache controller are similar to those of the AXI Master on the CPU side, and also support the same AxSIZE, AxLEN, and AxBurst. In addition, when the Cache controller acts as an AXI Master, its AxSIZE is fixed at 8B, AxLEN supports 4 or 8, and AxBurst also supports INCR and WRAP. These parameters reflect the performance of the Cache controller in data transfer and cache management.

[0059] The configuration of the Cache Memory includes a cache capacity of 128KB, a cache line size of 32B, and a 4-bank and 8-way set-associative structure. The functions supported by the Cache include read / write allocation, write-back, write-through, prefetch, and support for single / double cache line allocation and loading. These functional parameters are crucial for the selection of test patterns because they directly affect the coverage and depth of the test.

[0060] Based on these parameters, we can select the appropriate test data types. Since the cache line size is 32B, test patterns can be designed to test the prefetch function of the Cache or the single / double cache line filling function. At the same time, considering the AxBurst type supported by both the CPU-side AXI Master and the Cache controller AXI Slave, we can select data volumes such as 32B and 64B to test the AXI pipeline streaming transmission. Therefore, the optional test data types include any combination of 1B, 2B, 4B, 8B, 16B, 32B, 64B, and 128B. When designing the data content of the test pattern, the data in each round should be different to ensure the comprehensiveness of the test.

[0061] Finally, the size of the test pattern is determined by two parameters: M represents the number of groups of the test pattern, and N represents the number of types of data. For example, if M is 6 and N is 7, it means there are 6 different test patterns, and each test pattern contains 7 different data types. Such a design can ensure that the test pattern can cover various possible data transmission and cache behaviors, thus ensuring the correctness and reliability of the SoC design.

[0062] Figure 6 Shows a complete cache test process, which detects possible errors or problems in the cache by systematically writing and reading data and comparing data consistency.

[0063] First, the test process starts, defining the start address (addr_start) and end address (addr_end) of the test. These addresses identify the cache space range to be tested. Then, the entire test space is cleared to ensure a clean test environment and avoid interference from previous data on the test results.

[0064] Before the test starts, record the start time (start_time), which is used to calculate the time consumed by the entire test process at the end of the test. Then, initialize two variables x and y, both with an initial value of 0. Variables x and y are used to track specific states or counts during the test process.

[0065] Next, enter a loop. The purpose of the loop is to generate test data (data) and write it to a specific cache address. In the loop, first check whether variables x and y meet specific conditions: whether x is less than or equal to M, and whether y is between 0 and N. If these conditions are met, the loop will continue to execute; if not, the loop will terminate.

[0066] Inside the loop, a test pattern is calculated based on the values of x and y, which is used to generate test data. Then, the calculated data value is written to the cache address specified by addr. After writing the data, the value (value) is read from the same address addr and compared with the previously written data to verify data consistency.

[0067] If the read value value is inconsistent with the written data, an error will be prompted. The error prompt can include the error type, the address where the error occurred, or other relevant information so that the tester can locate and solve the problem.

[0068] In each loop iteration, the value of addr is updated according to addr_step to move to the next test address in the cache. At the same time, the values of x and y are also updated according to a specific algorithm to generate a new test pattern. The loop will continue to execute until the value of addr exceeds the test end address addr_end.

[0069] When the test loop is completed, the end time (end_time) is recorded, and the total elapsed time (diff) of the test process is calculated, which is obtained by subtracting the start time from the end time. Finally, the test process ends, and the tester can evaluate the performance and reliability of the cache based on the test results and elapsed time.

[0070] It should be noted that when designing the cache test process for the SoC, multiple factors need to be considered, including the characteristics of the AXI bus, the configuration of the cache function, and the selection of the test pattern, to ensure that the performance of the SoC external cache can be comprehensively evaluated. The following are the detailed test purposes and methods:

[0071] AXI bus transfer test:

[0072] The test pattern is designed to cover all possible transfer types between the CPU AXI Master and the cache controller. This includes INCR1 transfers, which support 8-bit, 16-bit, 32-bit, and 64-bit read and write operations, and INCRN transfers, where N ranges from 1 to 4 and is specifically used for 64-bit read and write.

[0073] In addition, it includes WRAP4 transfers, which are used for 64-bit read and write operations. These transfer types can ensure that we can test the performance of the AXI bus under different data widths and transfer modes.

[0074] Cache function test: Through the above tests, the attributes of the area to be tested are configured to support read allocation, write allocation, and write-back. After multiple rounds of testing, all areas of the cache will be traversed to ensure that the test can reach every part of the cache.

[0075] The test method first performs a write operation and then a read operation, which is the same principle as allocating cache lines on a read miss. During the write operation, if there is a miss, a new cache line will be allocated, and the write-back operation occurs when the cache line is replaced.

[0076] Full coverage of cache space and functions: By changing the parameters M, N, and Z in the test mode, as well as the specific test data, all cache spaces and functions can be covered. This flexibility allows us to adjust the test mode according to different test requirements to ensure comprehensiveness.

[0077] Performance evaluation: The time recorded during the test process can be used to evaluate the time required for different test modes. By comparing these times, the performance of the external cache can be indirectly evaluated. This method provides a performance benchmark, which helps to understand the performance of the external cache under different workloads.

[0078] Figure 7 Shows a detailed test process in an embodiment of the present invention. The AXI bus width is 64 bits, that is, 8 bytes (8B). The test mode is selected according to the previous description. The cache line size is 32 bytes (32B), and there are 4 memory banks. The attributes of the test area are set to support read allocation, write allocation, write-back, and the prefetch function is enabled. At the same time, dual cache line allocation and dual cache line increment (INCR) transfer are also enabled, but dual cache lines on the wrap transfer are turned off.

[0079] In the test process, the selection of parameters M, N, and Z has a direct impact on the test results. For example, when M = 6, N = 6, Z = 1, it means that 6 rounds of tests will be carried out, and 6 data patterns will be tested in each round. Different colors are used in the test to represent different test data types, such as 1B in blue, 2B in green, 4B in orange, etc. Each small solid grid represents an AXI transfer, and each large rectangle represents a cache line. The address marker is in units of cache line size, and the X value (0, 1, 2, 3, 4, 5) represents the 6 loops in the flow chart. For example, X = 0 represents the first loop, reading and writing 1B, 2B, 4B... in sequence; X = 1 represents the second loop, reading and writing 64B, 32B, 16B... in reverse order; and so on.

[0080] In an embodiment of the present invention, when performing a cache test on the L3 Memory, the test start address is first set to 0x0.

[0081] As Figure 7As shown, in the first round of testing (X = 0), starting from address 0x0, 1B of data is written. Since it is the first access, the cache misses, so two cache lines, Addr0 and Addr1, are allocated. Using the INCR1 mode of the AXI bus, an 8-bit transfer is performed to write the 1B of data to the first byte of the Addr0 cache line and mark this cache line as dirty (Dirty), but it is not immediately written back to the L3 Memory. Subsequently, a read operation is performed to read 1B of data through the INCR1 mode. This read will hit the Addr0 cache line. The read data will be compared with the expected value. If they are not equal, the test fails and exits; if they are equal, the address addr is incremented by 1B and y is incremented by 1 to prepare for the next round of testing.

[0082] In the second round of testing (X = 1), the address is incremented to 0x01 and 2B of data is written. Since 2B of data requires 16-bit alignment and the current address 0x1 is not aligned, the AXI bus will first perform a 1B INCR1 transfer and then another 1B INCR1 transfer to complete the writing of the 2B of data. This write will hit the Addr0 cache line, update the data in this line, and mark it as dirty. Then, the 2B of data is read in two INCR1 operations. If the read data is not equal to the expected value, the test fails; if it is equal, the address addr is incremented by 2B and y is incremented by 1.

[0083] It should be noted that in the second round of testing, the reason for the need to perform two INCR1 transfers is due to the requirements of data alignment and the AXI bus transfer characteristics. Specifically: in the second round of testing, if 2B of data is written and the address 0x1 is not aligned (because the AXI bus width is 8B, i.e., 64 bits), then a direct 2B transfer cannot be performed because this will cause an address misalignment problem. To solve this problem, the AXI bus will first perform a 1B INCR1 transfer to fill in the extra bytes required for alignment, and then start the remaining 1B transfer from the next aligned address to complete the writing of the 2B of data.

[0084] In the third round of testing (X = 2), the address is incremented to 0x03 and 4B of data is written. Since 4B of data requires 32-bit alignment and the current address 0x3 is not aligned, the AXI bus will first perform a 1B INCR1 transfer and then start a 4B INCR1 transfer from address 0x4. This write will hit the Addr0 cache line, update the data in this line, and mark it as dirty. Subsequently, the 4B of data is read in two AXI transfers. If the read data is not equal to the expected value, the test fails; if it is equal, the address addr is incremented by 4B and y is incremented by 1.

[0085] In the fourth round of testing (X = 3), the address increments to 0x07 and 8B of data is written. Since 8B of data needs to be 64-bit aligned and the current address 0x7 is not aligned, the AXI bus will first perform a 1B INCR1 transfer and then an 8B INCR1 transfer starting from address 0x8. This write will hit the Addr0 cache line, update the data in that line, and mark it as dirty. Then, the 8B of data is read in two AXI transfers. If the data read is not equal to the expected value, the test fails; if it is equal, the address addr increments by 8B and y increments by 1.

[0086] In the fifth round of testing (X = 4), the address increments to 0x0F and 16B of data is written. Since 16B of data needs to be 128-bit aligned and the current address 0xF is not aligned, the AXI bus will first perform a 1B INCR1 transfer and then an 8B INCR2 transfer starting from address 0x10. This write will hit the Addr0 cache line, update the data in that line, and mark it as dirty. Subsequently, the 16B of data is read in three AXI transfers. If the data read is not equal to the expected value, the test fails; if it is equal, the address addr increments by 16B and y increments by 1.

[0087] In the sixth round of testing (X = 5), the address increments to 0x1F and 32B of data is written. Since 32B of data needs to be 256-bit aligned and the current address 0x1F is not aligned, the AXI bus will first perform a 1B INCR1 transfer and then an 8B INCR4 transfer starting from address 0x20. This write will hit the Addr0 cache line, update the data in that line, and mark it as dirty. Then, the 32B of data is read in five AXI transfers. If the data read is not equal to the expected value, the test fails; if it is equal, the address addr increments by 32B and y increments by 1.

[0088] Each round of testing is consecutive and must be successfully completed to proceed to the next round. This method of gradually increasing the data size allows us to comprehensively test the behavior of the cache under different loads. During the testing process, it is necessary to closely monitor the allocation of cache lines, the behavior of marking as dirty, and whether the data is correctly written and read.

[0089] During the above cache testing process, to address potential exceptions that may occur during cache line replacement, we implemented various cache line replacement strategies. These strategies include Pseudo-Random Replacement and Round-Robin Victim Selection. Among them, the pseudo-random replacement strategy is a method for selecting the cache line to be replaced. Under this strategy, when a cache line needs to be replaced, a cache line is randomly selected from all available cache lines for replacement. The "pseudo-random" part of this strategy means that the selection process is deterministic but appears random, usually implemented through a predefined pseudo-random algorithm. The round-robin victim selection strategy is a method of cycling through cache lines to select the next cache line to be replaced. In this strategy, the system maintains a pointer or counter. Each time a cache miss occurs, the pointer moves sequentially to the next cache line. When the pointer reaches the end of the cache line array, it loops back to the start of the array, forming a cycle. The advantage of this strategy is that it is simple and fair because it ensures that each cache line has an equal chance of being replaced. This helps prevent certain cache lines from occupying cache space for a long time due to frequent access, thereby improving cache utilization. The above strategies optimize the cache usage efficiency by intelligently selecting the cache line to be replaced, helping to increase the cache hit rate, reduce data loading caused by cache misses, and ensure the smooth progress of the entire cache testing process.

[0090] It should be noted that the above embodiments are only examples. The technical solutions of each embodiment can be combined, and all are within the protection scope of the present invention.

[0091] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the present invention, "a plurality" means two or more, unless otherwise specifically defined.

[0092] The above provides a detailed description of the SoC external cache testing method for testability design provided by the present invention. For those of ordinary skill in the art, any obvious changes made without departing from the essence of the present invention will constitute an infringement of the patent right of the present invention and will bear corresponding legal responsibilities.

Claims

1. A SoC cache test method for design for testability, characterized in that It includes the following steps: (1) Isolate the L1 Cache in the SoC; among them, configure the attributes of the instruction area to be cacheable so that instructions are stored in the L1 instruction Cache, and set other address areas to be non-cacheable to reduce unnecessary access to the L2 Cache; (2) Define a test space with a preset size and configure it to be cacheable for storing and accessing test data; determine the size of the test space according to the cache hierarchy in the SoC and the relationship between different cache layers to ensure that all potential cache areas can be covered; among them, when the test target is the L2 Cache, if there is an inclusive relationship between the L1 Cache and the L2 Cache, the size of the test space is at least twice the size of the L2 Cache; if there is an exclusive relationship between the L1 Cache and the L2 Cache, the size of the test space is at least the size of the L1 Cache plus twice the size of the L2 Cache; when the test target is the L3 Cache, if there is an inclusive relationship between the L1 Cache, the L2 Cache and the L3 Cache, the size of the test space is at least twice the size of the L3 Cache; if there is an exclusive relationship between the L1 Cache, the L2 Cache and the L3 Cache, the size of the test space is at least the size of the L1 Cache plus the size of the L2 Cache, plus twice the size of the L3 Cache; (3) Before the test starts, keep the L2 Cache in the off state to ensure that only the preset test instructions will pass through the L2 Cache during the test; (4) At the start of the test, enable the L2 Cache and ensure that the preset test instructions are fixed in the L2 Cache by configuring the L2 Cache controller; (5) Use the MBIST test algorithm to test the entire test space to detect the data integrity and functionality of the L2 Cache; among them, the AXI bus first performs a 1B INCR1 transfer to fill in the extra bytes required for alignment, and then starts the remaining 1B transfers from the next aligned address to complete the writing of 2B data; a pseudo-random replacement strategy is adopted to implement the replacement of cache lines during the cache test; in the pseudo-random replacement strategy, when a cache line needs to be replaced, a random one is selected from all available cache lines for replacement.

2. The SoC cache test method according to claim 1, wherein: In the step (4), the preset instructions fixed in the L2 Cache include turning on the L2 Cache, writing test data to specific memory addresses, reading data from these addresses, and comparing whether the read data is consistent with the expected value.

3. The SoC cache test method according to claim 1, wherein: In the step (4), different test patterns are written in the test space, and then the data is read and compared to verify its integrity and consistency; wherein, the number of the test instructions does not exceed 10.

4. The SoC cache test method according to claim 3, wherein: The size of the test pattern is determined by two parameters M and N, where M represents the number of groups of the test pattern, and N represents the number of types of data types.

5. The SoC cache test method according to claim 1, wherein: In the step (5), the cache line replacement is implemented by adopting a cyclic rotation victim selection strategy; in the cyclic rotation victim selection strategy, a pointer is maintained, and each time a cache miss occurs, the pointer moves to the next cache line in sequence; when the pointer reaches the end of the cache line array, it loops back to the beginning of the cache line array to form a cycle.

Images