SoC cache test method oriented to testability design

Abstract

The invention discloses an SoC (System on Chip) cache test method oriented to testability design. According to the method, the L1Cache is isolated, the instruction area is configured to be cacheable, so that unnecessary access to the L2Cache is reduced, meanwhile, the test space with the preset size is defined, and it is ensured that all potential cache areas are covered. Before the test is started, the L2Cache is kept closed, the L2Cache is started when the test is started, and a test instruction is ensured to be fixed in the L2Cache by configuring an L2Cache controller. And an MBIST test algorithm is adopted to comprehensively test the test space so as to detect the data integrity and functionality of the L2Cache. Through the measures, the problems possibly existing in the SoC cache can be effectively detected, the yield of chips is improved, and the production cost is reduced.

Description

Technical Field

[0001] The invention relates to a cache testing method, in particular to a SoC cache testing method oriented to testability design, and belongs to the technical field of integrated circuit testing. Background Art

[0002] With the continuous advancement of integrated circuit technology, the integration of chips is getting higher and higher. The widespread application of advanced structures such as Fin-FET in IC design has made the testing cost account for a considerable proportion of the entire 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) came into being and was closely integrated with the design process in the early stages 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 discovering defects that may occur in the manufacturing process, such as open circuits, short circuits, and other problems.

[0003] During the DFT test phase of a chip, it is crucial to ensure the integrity of the cache, because if the cache problem is not fully detected, it may cause defective chips to flow into the market, causing economic losses to the manufacturer. In order to solve this problem, in addition to the existing MBI ST (Memory Built-In Self-Test) technology, testing the cache through software has become an effective technical means. By simulating different usage scenarios and data patterns, software testing can detect the performance and stability of the cache under various working conditions, thereby identifying and fixing potential problems in advance. In the current system-on-chip (SoC) design, the proportion of external cache is increasing. This makes the development of an effective SoC external cache test method essential to improving the chip yield and reducing production costs.

[0004] In the Chinese invention patent with patent number ZL 201880098721.7, a method for testing an operationally adaptive integrated circuit is disclosed. The method allows the performance of the integrated circuit to be adjusted by configuring the values ​​of the operational parameters. The specific method includes: setting the integrated circuit to a test mode, which is different from the normal working mode of the circuit; in the test mode, inputting a test signal consisting of a specific test value into one or more adaptive processing paths of the circuit. These processing paths include processing logic and buffer circuits, which generate output values ​​based on the input values, and can adjust the performance 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, these test results are finally used to select and set the values ​​of the operational parameters of the integrated circuit. This method helps to improve the testing efficiency and accuracy of integrated circuits. Summary of the invention

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

[0006] In order to achieve the above object, the present invention adopts the following technical methods:

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

[0008] (1) Isolating the L1 Cache in the SoC; wherein the attribute of the instruction area is configured as cacheable so that the instructions are stored in the L1 instruction cache, and other address areas are set as non-cacheable to reduce unnecessary access to the L2 cache;

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

[0010] (3) Before the test begins, keep the L2 Cache closed to ensure that only the preset test instructions pass through the L2 Cache during the test;

[0011] (4) At the beginning of the test, the L2 Cache is enabled, and the L2 Cache controller is configured to 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), the size of the test space is determined based on the hierarchical structure of the cache in the SoC and the relationship between different cache layers to ensure that all potential cache areas are covered.

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

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

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

[0017] Preferably, in step (4), different test modes are written into the test space, and then the data are read and compared to verify their integrity and consistency; wherein 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 test pattern groups and N represents the number of data types.

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

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

[0021] Preferably, in step (5), a cyclic rotation victim selection strategy is used to implement cache line replacement; in the cyclic rotation victim selection strategy, a pointer is maintained, and each time the cache fails, 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 loop.

[0022] Compared with the prior art, the SoC cache test method provided by the embodiment of the present invention effectively reduces unnecessary access to the L2 Cache by isolating the L1Cache 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 fully covered. In addition, the MB IST test algorithm and software simulation technology are used to simulate various usage scenarios and data patterns, and detect the performance and stability of the cache under different working conditions. The use of the present invention helps to identify and repair potential problems of the SoC external cache in advance, effectively improve the chip yield and reduce production costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A schematic diagram of the connection between the MB IST controller and the cache controller in the prior art;

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

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

[0026] Figure 4 This is an example diagram of a cache structure in an embodiment of the present invention;

[0027] Figure 5 A schematic diagram of a cache system with a 32-bit physical address in an embodiment of the present invention;

[0028] Figure 6 A flowchart of a cache testing process provided by an embodiment of the present invention;

[0029] Figure 7 A schematic diagram of the read and write status of data in a cache structure during six rounds of testing performed for an embodiment of the present invention. DETAILED DESCRIPTION

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

[0031] Figure 1 The figure is a typical connection diagram between an MBI ST controller and a cache controller in the prior art. The figure shows a configuration method for performing MBI ST testing on a cache controller without using data bank ing 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 MB IST test process. The cache controller manages all cache operations, including data reading and writing and the implementation of cache strategies. In addition, Data parity RAMs are used to store parity information of data to ensure data integrity. Data RAMs are random access memories used for data storage in the cache, while Tag RAMs store tag information of cached data, which is essential for rapid retrieval and identification of data.

[0032] As we all know, in order to improve the performance and response speed of the processor (CPU) in the system-on-chip (SoC), a multi-level cache system is usually integrated, such as L1Cache, L2Cache and L3Cache. The most basic configuration includes at least one level of cache, namely L1Cache, which is directly integrated into the core of the CPU. For a multi-core processor system, each CPU core has its own L1Cache, which ensures that each core can quickly access its own data and instructions, reducing contention and latency between cores.

[0033] L1Cache is usually further divided into L1DataCache and L1InstructionCache. Among them, the data cache is used to store recently accessed data, while the instruction cache is used to store recently executed instructions. This separation design helps to improve the efficiency of the cache because data and instructions often have different access patterns and locality characteristics. The independence of data cache and instruction cache allows the CPU to perform special optimizations on them. For example, the data cache may implement a more complex prefetch strategy, while the instruction cache may use a more efficient branch prediction technology.

[0034] In some SoC designs, in addition to the L1Cache inside each core, there may also be a shared L2Cache. The capacity of L2Cache is usually larger than L1Cache, and it provides a larger shared cache space for multiple cores to reduce the need to access the system main memory. In some SoC architectures, L2Cache may be private to each CPU core, while in other architectures, it may be shared by multiple cores. The design of shared L2Cache helps improve the consistency and availability of data between cores, but it also increases the complexity of the cache system.

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

[0036] like Figure 3 As shown in the figure, in some SoC designs that include L2 Cache, L3 Cache may not exist. In this case, if a larger cache capacity or a more complex cache hierarchy is required, an external L3 Cache is required. L3 Cache is usually a larger shared cache that serves all CPU cores in the entire SoC. The introduction of L3 Cache further increases the cache capacity and system complexity, but also increases the possibility of data reuse, thereby reducing the frequency of access to the main memory.

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

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

[0039] exist Figure 4 In 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 vertical rows 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 a "Way". This structured design enables the cache to efficiently store and retrieve data, while also supporting complex cache consistency protocols.

[0040] like Figure 5 As shown in the figure, 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 128KB, and an 8-way set associative and 4 storage area cache configuration is adopted, we can define the variables in the cache structure based on these parameters. Specifically, X represents the number of storage areas in each Cache RAMs, where X is equal to 4; Y represents the number of set-associative ways, where Y is equal to 8; and N represents the number of cache lines in each way. By calculation, N is equal to 128KB divided by (the number of storage areas multiplied by the cache line size), that is, 128KB / (4*32B)=512. Such a configuration allows the cache system to store and access data in an efficient manner, while ensuring that the cache organization structure can meet specific performance requirements. Figure 5 These parameters 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 storage areas will directly affect the overall performance and capacity of the cache.

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

[0042] In order to make up for the shortcomings of the current MBI ST technology, the embodiment of the present invention proposes a SoC cache test method oriented to testability design. The test method aims to perform a comprehensive test on the entire L2 Cache space by simulating the existing MBI ST technology through software.

[0043] Specifically, the L1Cache needs to be isolated first. This is because the L1Cache is divided into instruction cache and data cache, which will interfere with the test of L2 Cache. To achieve this, only the attribute of the instruction area is configured as cacheable, which means that the instruction can be stored in the L1Cache, while other address areas are set to 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 storage and access of test data. It should be noted that the test space is usually implemented by RAMs (random access memory). This design choice is intended to provide a controllable and reliable test environment to accurately evaluate the performance and reliability of the L2 Cache. The preset size of the test space is carefully designed to cover at least 128K of the L2 Cache Memory. This is to ensure that the test can touch all potential areas of the cache, thereby discovering problems that may exist in different cache areas.

[0045] When determining the size of the test space, you first need to understand the cache hierarchy in the SoC and the relationship between different cache layers. As mentioned earlier, an SoC can contain multiple levels of cache, such as L1, L2, and L3 cache, and the relationship between them can be inclusive or exclusive. These relationships are crucial to determining the size of the test space.

[0046] When the test target is L2 Cache, if L1Cache and L2 Cache are inclusive, it means that L2Cache contains all the data of L1Cache, so the size of the test space should be at least twice the size of L2 Cache. Doing so can ensure that the data in L2 Cache can be completely replaced during the test, thereby detecting possible cache line replacement problems. If L1Cache and L2 Cache are exclusive, the size of the test space should be at least the size of L1Cache plus twice the size of L2 Cache (i.e. L1Cache Size + L2 Cache Size * 2). This configuration allows the test to cover data exchange and cache consistency between L1Cache and L2Cache.

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

[0048] Before conducting software testing of L2 Cache, L1Cache must be isolated first, because L1Cache is divided into instruction cache and data cache, which may interfere with L2 Cache testing. To achieve isolation, only the attribute of the instruction area is configured as cacheable, which means that instructions can be stored in L1 instruction cache, while other address areas are set to non-cacheable to reduce unnecessary access to L2Cache.

[0049] Before the test begins, the L2 Cache is kept closed to ensure that only a very small number of instructions will pass through the L2 Cache during the test, thereby reducing the interference of instructions on the L2 Cache and providing a purer test environment. This step is critical because it allows test engineers to focus on data testing without being potentially affected by instruction flow.

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

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

[0052] The purpose of fixing instructions in the L2 Cache is to precisely control and observe the behavior of the cache system, especially in a test environment. This allows test engineers to specifically monitor and analyze the flow and changes of data from the L1Cache data bus to the L2 Cache without being potentially interfered with by the L1Cache instruction bus to the L2 Cache. Specifically, these instructions fixed in the L2 Cache include opening 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.

[0053] Finally, the MBI ST test algorithm is used to test the entire test space. In this way, the mature MBI ST test technology can be used to detect the data integrity and functionality of the L2 Cache. In this way, the data access pattern in actual applications can be simulated, in which the number of data read and write operations far exceeds the number of control instructions, thereby ensuring the performance and stability of the L2 Cache under various conditions.

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

[0055] When performing software testing of L2 Cache, the core of the test strategy is to ensure that the impact of test instructions on the cache is minimized in order to leave as much space as possible for data testing. To this end, the design of the test code adopts an efficient traversal mechanism, the purpose of which is to write different test patterns (Patterns) in the test space, and then read and compare these data to verify their integrity and consistency. In 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] The test mode used in the embodiment of the present invention is specifically described as follows:

[0057] When designing the test mode, it is necessary to consider the relevant properties of two key modules: the AXI interface reserved by the CPU and the configuration of the cache. The properties of the AXI Master interface on the CPU side include the supported bus width (AxS IZE), bus transfer length (AxLEN), and bus transfer type (AxBurst). These parameters determine the data transmission capabilities. For example, the width supported by AxS I ZE is 1B, 2B, 4B, and 8B, the transfer length supported by AxLEN is 1 to 16B, and the types supported by AxBurs t include INCR (incremental) and WRAP (wrapped).

[0058] When the cache controller is used as an AXI Slave, its parameters are similar to those of the CPU-side AXI Master, and it also supports the same AxS IZE, AxLEN, and AxBurst. In addition, when the cache controller is used as an AXI Master, its AxS I ZE is fixed to 8B, AxLEN supports 4 or 8, and AxBurst also supports INCR and WRAP. These parameters reflect the performance of the cache controller in data transmission and cache management.

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

[0060] Based on these parameters, we can select the appropriate test data type. Since the cache line size is 32B, a test pattern can be designed to test the cache prefetch function or the single and double cache line fill function. At the same time, considering that both the CPU-side AXI Master and the Cache controller AXI Slave support the AxBurst type, we can choose 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, each round of data 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 test pattern groups, and N represents the number of data types. For example, if M is 6 and N is 7, it means there are 6 different test patterns, each containing 7 different data types. This design ensures that the test pattern can cover all possible data transfer and cache behaviors, thereby 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 the consistency of the data.

[0063] First, the test process is started, and the starting address (addr_start) and ending address (addr_end) of the test are defined. These addresses identify the cache space range to be tested. Then, the entire test space is cleared to ensure the cleanliness of the test environment and avoid previous data from interfering with the test results.

[0064] Before the test begins, the start time (start_time) is recorded so that the time taken for the entire test process can be calculated at the end of the test. Then, two variables x and y are initialized to 0. Variables x and y are used to track specific states or counts during the test.

[0065] Next, a loop is entered, the purpose of which is to generate test data and write it to a specific cache address. In the loop, variables x and y are first checked to see if they meet certain 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, and this test pattern 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 the consistency of the data.

[0067] If the read value is inconsistent with the written data, an error message will be displayed. The error message may 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 in order 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 is executed until the value of addr exceeds the test end address addr_end.

[0069] When the test cycle is completed, the end time (end_time) is recorded and the total 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 time.

[0070] It should be noted that when designing a cache test process for 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 mode to ensure that the performance of the SoC external cache can be fully evaluated. The following are detailed test objectives and methods:

[0071] AXI bus transmission 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, specifically for 64-bit reads and writes.

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

[0074] Cache functional testing: Through the above tests, the properties 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 touch every part of the cache.

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

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

[0077] Performance evaluation: The times 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 baseline that helps understand how the external cache performs under different workloads.

[0078] Figure 7 A detailed test flow in an embodiment of the present invention is shown, wherein the AXI bus width is 64 bits, i.e., 8 bytes (8B), and the test mode is selected according to the previous description. The cache line size is 32 bytes (32B), and there are 4 storage areas. The properties of the test area are set to support read allocation, write allocation, write back, and the prefetch function is enabled. At the same time, double cache line allocation and double cache line increment (INCR) transfer are also enabled, but double cache lines on wrap (WRAP) transfers are turned off.

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

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

[0081] like Figure 7As shown, in the first round of testing (X=0), 1B data is written starting from address 0x0. Since it is the first access, the cache misses, so two cache lines, Addr0 and Addr 1, are allocated. Using the INCR1 mode of the AXI bus, an 8-bit transfer is performed to write 1B data to the first byte of the Addr0 cache line, and the cache line is marked as dirty, but it is not immediately written back to the L3 Memory. Subsequently, a read operation is performed to read 1B data through the INCR1 mode, and this read will hit the Addr0 cache line. The read data is 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, preparing for the next round of testing.

[0082] In the second round of testing (X=1), the address is incremented to 0x01 and 2B data is written. Since 2B data needs to be 16-bit aligned, and the current address 0x1 is not aligned, the AXI bus will first perform 1B of INCR 1 transmission, and then perform 1B of INCR1 transmission to complete the writing of 2B data. This write will hit the Addr0 cache line, update the data of the line, and mark it as dirty. Next, read 2B data in two INCR 1s. If the read data is not equal to the expected value, the test fails; if they are 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 why two INCR 1 transmissions are required is due to the requirements of data alignment and AXI bus transmission characteristics. Specifically: in the second round of testing, if 2B data is written and address 0x 1 is not aligned (because the AXI bus width is 8B, i.e. 64 bits), then the 2B transmission cannot be performed directly because it will cause the address misalignment problem. To solve this problem, the AXI bus will first perform a 1B INCR 1 transmission to fill the extra bytes required for alignment, and then perform the remaining 1B transmission starting from the next aligned address to complete the writing of 2B 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 needs to be 32-bit aligned, and the current address 0x3 is not aligned, the AXI bus will first perform a 1B INCR1 transfer, and then perform a 4B INCR 1 transfer starting from address 0x4. This write will hit the Addr0 cache line, update the data in the line, and mark it as dirty. Subsequently, 4B of data is read in two AXI transfers. If the read data is not equal to the expected value, the test fails; if they are 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 is incremented 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 perform an 8B INCR 1 transfer starting from address 0x8. This write will hit the Addr0 cache line, update the data in the line, and mark it as dirty. Next, read 8B of data in two AXI transfers. If the read data is not equal to the expected value, the test fails; if they are equal, the address addr is incremented by 8B and y is incremented by 1.

[0086] In the fifth round of testing (X=4), the address is incremented 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 INCR 1 transfer, and then perform an 8B INCR2 transfer starting from address 0x10. This write will hit the Addr0 cache line, update the data in the line, and mark it as dirty. Subsequently, 16B of data is read in three AXI transfers. If the read data is not equal to the expected value, the test fails; if they are equal, the address addr is incremented by 16B and y is incremented by 1.

[0087] In the sixth round of testing (X=5), the address is incremented 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 perform an 8B INCR4 transfer starting from address 0x20. This write will hit the Addr0 cache line, update the data in the line, and mark it as dirty. Next, read 32B of data in five AXI transfers. If the read data is not equal to the expected value, the test fails; if they are equal, the address addr is incremented by 32B and y is incremented by 1.

[0088] Each round of testing is continuous and must complete successfully to proceed to the next round. This approach of gradually increasing the data size allows us to fully test the behavior of the cache under different loads. During the test, close attention needs to be paid to the allocation of cache lines, the behavior of marking as dirty, and whether data is written and read correctly.

[0089] In the cache test process described above, in order to deal with the anomalies that may be caused when the cache line is replaced, we implemented a variety of 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 of selecting a cache line to be replaced. Under this strategy, when a cache line needs to be replaced, one 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 looks random, usually achieved through a pre-defined pseudo-random algorithm. The round-robin victim selection strategy is a method of looping through cache lines to select the next cache line to be replaced. In this strategy, the system maintains a pointer or counter, and each time the cache is invalidated, 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 array, forming a loop. The advantage of this strategy is that it is simple and fair, because it ensures that each cache line has the same chance to be 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 strategy optimizes cache usage efficiency by intelligently selecting cache lines to be replaced, which helps improve cache hit rate, reduce data loading caused by cache failure, and ensure the smooth progress of the entire cache test process.

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

[0091] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0092] The above is a detailed description of the SoC external cache test method for testability design provided by the present invention. For those skilled in the art, any obvious changes made to it 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 testability design, characterized in that The following steps are involved: (1) Isolating the L1 Cache in the SoC; wherein the attribute of the instruction area is configured as cacheable so that the instructions are stored in the L1 instruction cache, and other address areas are set as non-cacheable to reduce unnecessary access to the L2 cache; (2) define a test space of a preset size and configure it to be cacheable for storing and accessing test data; (3) Before the test begins, keep the L2 Cache closed to ensure that only the preset test instructions pass through the L2 Cache during the test; (4) At the beginning of the test, the L2 Cache is enabled, and the L2 Cache controller is configured to ensure that the preset test instructions are fixed in the L2 Cache; (5) Use the MBIST test algorithm to test the entire test space to detect the data integrity and functionality of the L2Cache.

2. The SoC cache testing method according to claim 1, wherein: In the step (2), the size of the test space is determined according to the hierarchical structure of the cache in the SoC and the relationship between different cache layers to ensure that all potential cache areas can be covered.

3. The SoC cache testing method according to claim 2, wherein: When the test target is L2 Cache, if there is an inclusive relationship between L1Cache and L2 Cache, the size of the test space is at least twice the size of L2 Cache; if there is an exclusive relationship between L1Cache and L2 Cache, the size of the test space is at least the size of L1Cache plus twice the size of L2 Cache.

4. The SoC cache testing method according to claim 2, wherein: When the test target is L3 Cache, if L1Cache, L2 Cache and L3 Cache are inclusive, the size of the test space is at least twice the size of L3 Cache; if L1Cache, L2 Cache and L3 Cache are exclusive, the size of the test space is at least the size of L1Cache plus the size of L2 Cache plus twice the size of L3Cache.

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

6. The SoC cache testing method according to claim 1, wherein: In the step (4), different test modes are written into the test space, and then the data are read and compared to verify their integrity and consistency; wherein the number of the test instructions does not exceed 10.

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

8. The SoC cache testing method according to claim 1, wherein: In the step (5), the AXI bus first performs a 1B INCR 1 transmission to fill the extra bytes required for alignment, and then performs the remaining 1B transmission starting from the next aligned address to complete the writing of 2B data.

9. The SoC cache testing method according to claim 1, wherein: In step (5), a pseudo-random replacement strategy is used to implement cache line replacement; in the pseudo-random replacement strategy, when a cache line needs to be replaced, one is randomly selected from all available cache lines for replacement.

10. The SoC cache testing method according to claim 1, wherein: In the step (5), a cyclic rotation victim selection strategy is used to implement cache line replacement; in the cyclic rotation victim selection strategy, a pointer is maintained, and each time the cache fails, 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 loop.

Images