Non-blocking L1 Cache in Multi-core SOC

Abstract

The present invention relates to a non-blocking L1 Cache in a multi-core SOC, wherein the L1 Cache comprises two circuit modules, an ICache and a DCache, wherein the ICache circuit module is designed as an 8-way group-associative dual-bank SRAM to provide data access for the CPU instruction fetching stage, and the DCache circuit module is designed as an 8-way group-associative single-bank SRAM to provide data access for the CPU LSU instruction fetching stage; the design of a control circuit and a pipeline in the ICache; the control circuit, pipeline, replacement algorithm, missing cache queue (MSHR) and consistency protocol in the DCache. The non-blocking L1 Cache in the multi-core SOC applied by the present invention solves the problems of low cache access efficiency and design difficulty in the existing multi-core SOC.

Description

Technical Field

[0001] The present invention relates to the technical field of computer architecture, and in particular to a non-blocking L1 Cache in a multi-core SOC. Background Art

[0002] With the development of semiconductor technology, the performance of memory has lagged far behind the development of processors. From the early 1980s to the early 21st century, processors developed rapidly at a rate of about 50% per year, while the performance of DRAM increased at a rate of only about 10% per year. The speed and bandwidth of processors and DRAM were seriously mismatched, and frequent access to DRAM would occupy a large amount of bus bandwidth. The locality principle of computer programs indicates that if a specific location in memory is accessed at a certain point, it is likely that the same location will be accessed again in the near future; if a specific storage location is accessed at a specific time, it is likely that a nearby storage location will be accessed in the near future. Therefore, in general-purpose processors CPU, a small and fast cache is often used to cache local data to reduce the processor's access to DRAM. When processing programs with locality, more than 90% of the data required by the processor can be hit in the cache, and the number of DRAM accesses will be greatly reduced. As a cache that directly interacts with the processor core CPU, the access efficiency of L1 Cache will directly affect the CPU's main frequency. The design of L1 Cache has always been the focus and hot spot in the field of computer architecture. Summary of the invention

[0003] Therefore, the technical problem to be solved by the present invention is to overcome the serious mismatch between the speed and bandwidth of the processor and DRAM in the prior art, thereby providing a non-blocking L1 Cache in a multi-core SOC based on the RISCV instruction set.

[0004] In order to solve the above technical problems, the present invention provides a non-blocking L1 Cache in a multi-core SOC, wherein the L1 Cache includes two circuit modules, an ICache and a DCache. The ICache circuit module is designed as an 8-way set-associative dual-bank SRAM to provide data access for the CPU instruction fetch stage, and the DCache circuit module is designed as an 8-way set-associative single-bank SRAM to provide data access for the CPU LSU instruction fetch stage, and further includes:

[0005] When the data needed by the core CPU of the SOC processor is missing in the cache, the CPU will not be blocked and wait for the data to be ready, but will put the instruction with unready data into the missing processing queue and continue to execute the next instruction. When the data is retrieved from the lower memory to the L1 cache, the instruction will be re-executed;

[0006] When the SOC processor core CPU modifies data and writes it back to the L1 Cache, the data in the L1 Cache is marked as dirty data. At the same time, when other CPUs in the SOC apply for access to the data, since the data is only updated in the local L1 Cache of the CPU that writes the data, the local L1 Cache of other CPUs does not have the latest copy of the data, and a consistency algorithm is needed to synchronize the data.

[0007] In one embodiment of the present invention, the missed operation is recorded in the cache miss queue, and the CPU is notified to re-execute the corresponding instruction after the data is retrieved from the L1 Cache, including:

[0008] Record the address of the missing instruction into the miss cache queue and notify the CPU to continue executing subsequent instructions;

[0009] At the same time, the address of the missing data is sent to the bus to notify the lower storage unit to transmit the corresponding data;

[0010] The required data is retrieved to the SRAM of the L1 Cache through the bus, and the previously stored missing instruction address is taken out from the missing cache queue to notify the CPU to execute the instruction again.

[0011] In one embodiment of the present invention, data consistency between multiple cores is maintained, and data between different cores has different data permissions. The consistency protocol defines four different permissions, namely, no local data, local data but only read permission, local data and read and write permissions, local data and read and write permissions, and dirty data, specifically including:

[0012] When the required data is not available locally and the current request is to read data, a request needs to be sent to the bus to read data from the remote end; when the data requested from the remote end is not marked as dirty data, the requested data is returned to the requesting end, and both the local and remote ends have the latest copies; when the data requested from the remote end is marked as dirty data, the dirty data needs to be written back to the lower-level memory first, and the data is returned to the local cache at the same time, and both the remote and local ends have the latest copies of the data;

[0013] When the required data is not available locally and the current request is to write data, a data request needs to be sent to the bus to read data from the remote end; when the data requested from the remote end is not marked as dirty data, a copy of the data is returned to the requesting end. After the local write operation, the local copy of the data is dirty data and the remote copy of the data is invalidated; when the data requested from the remote end is marked as dirty data, a copy of the data needs to be written back first and the data is returned to the requesting end. At this time, the remote data copy becomes a Branch or Trunk. After the requesting end writes data, the local data is marked as dirty data and the remote data is invalidated;

[0014] When there is a local copy of the data, it means that there is no dirty data in the local cache of all cores. When the data needs to be read, it is read directly through the local cache; when the data needs to be written, first determine whether the permissions corresponding to the local data are sufficient. If the permissions are sufficient, the data is written directly, otherwise the data permissions need to be upgraded before writing the data. At the same time, other core data are invalidated and the local data permissions are changed to Dirty.

[0015] In one embodiment of the present invention, the dirty data needs to be written back. There are two ways to write back. One is to write back the data during the consistency maintenance according to claim 3, and the other is that the CPU actively writes back the dirty data, including:

[0016] When consistency maintenance involves dirty data, the data needs to be written back to the next level of storage while maintaining consistency;

[0017] When too much dirty data accumulates locally, the CPU will actively process all the dirty data in a pipeline at one time.

[0018] In one embodiment of the present invention, an independent cache ICache needs to be designed to provide instructions for the CPU instruction fetch stage, including:

[0019] When the instruction fetch IF stage in the CPU pipeline needs the instruction corresponding to the program counter PC, the instruction corresponding to the corresponding address will be taken out from the ICache and returned to the CPU;

[0020] ICache only needs to provide data access to the CPU during the instruction fetch stage. The CPU does not return data to ICache. All data in ICache comes from the lower-level memory writing to ICache through the bus. Data that does not exist becomes dirty data after being written by the CPU. Therefore, there is no need to provide consistency maintenance and data write-back support for ICache.

[0021] In one embodiment of the present invention, an independent cache DCache needs to be designed to provide data access and cache for the SLU stage of the CPU, including:

[0022] When a load instruction is issued, the data corresponding to the requested address needs to be provided to the CPU. When a save instruction is executed, the corresponding data needs to be cached to the corresponding address, and the permission of the data in the DCache is set to Dirty.

[0023] Since the LSU module not only needs to access the DCache, but also needs to write data, which causes the data in the DCache to become dirty data, a consistency maintenance and write-back module needs to be added to the DCache. At the same time, in order to improve the performance of the CPU, when the data that the LSU needs to access is not in the DCache, the CPU will not enter a waiting state due to the lack of the data, but will instead switch to executing other instructions that are not related to the instruction. Therefore, a missing cache processing mechanism needs to be added.

[0024] The above technical solution of the present invention has the following advantages over the prior art: the DCache in the non-blocking L1Cache in the multi-core SOC of the present invention not only provides data access but also provides data caching. After the processor CPU modifies the data, it will be written into the cache. At this time, the caches of different processor CPUs may have old copies of the data and need to be accessed. At this time, it is necessary to use the consistency protocol to transfer the data to the target CPU through the write-back strategy. At the same time, after the instructions are reordered, the correlation between different instructions can be determined. When the data address to be accessed is missing in the cache, the subsequent unrelated instructions can continue to be executed. Therefore, the design of DCache is usually non-blocking. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to make the contents of the present invention more clearly understood, the present invention is further described in detail below based on specific embodiments of the present invention in conjunction with the accompanying drawings.

[0026] Figure 1 ICache corresponding data_array structure diagram provided for an implementation of the present invention

[0027] Figure 2 An ICache architecture diagram is provided for one implementation of the present invention.

[0028] Figure 3 A DCache corresponding data_array structure diagram is provided for an implementation of the present invention.

[0029] Figure 4 A Dcache architecture diagram is provided for one implementation of the present invention.

[0030] Figure 5 A writeback module state machine diagram is provided for one implementation of the present invention.

[0031] Figure 6 A prober module state machine diagram is also provided for implementation of the present invention. DETAILED DESCRIPTION

[0032] This embodiment provides a non-blocking L1 Cache in a multi-core SOC. The L1 Cache includes two circuit modules, an ICache and a DCache. The ICache circuit module is designed as an 8-way set-associative dual-bank SRAM to provide data access for the CPU instruction fetch stage, specifically including:

[0033] Accepts requests from the instruction fetch stage in the CPU pipeline;

[0034] Divide bits 11-6 of the requested address into bits 31-12 of the idx address and use them as tags. idx is used to index the corresponding group number, and tag is used to compare whether there is a match.

[0035] The corresponding valid bit and tag are taken out through idx. If the valid bit is valid, the 8 tags are compared with the tag requested by the CPU to see if they match. If they match, it is judged as a hit and the corresponding data is returned; if they do not match, it is reported as missing;

[0036] The CPU requesting missing data will request the missing data from the bus;

[0037] When the data returns from the bus, it will be filled into the corresponding storage unit of ICache, and the valid bit will be set to 1;

[0038] During this period of missing data, the CPU will request the instruction in a loop. When the data is filled, the CPU request will be hit and the next instruction will be executed.

[0039] The DCache circuit module is designed as an 8-way set-associative single-bank SRAM to provide data access for the CPU LSU instruction fetch stage, including:

[0040] Accept data access and storage requests from the CPU;

[0041] Divide bits 11-6 of the requested address into bits 31-12 of the idx address and bits tag. idx is used to index the corresponding group number, and tag is used to compare whether there is a match.

[0042] The corresponding permission meta and tag are retrieved through idx. If there is a permission that matches the required operation, the 8 tags are compared with the tags requested by the CPU to see if they match. If they match, the operation requested by the CPU is performed and the corresponding data is returned; if they do not match, the missing data is reported.

[0043] Actively or passively write back data with Dirty permissions;

[0044] When the data accessed by the remote end is dirty locally, consistency maintenance is required;

[0045] When the data currently to be accessed is missing locally, the instruction operation corresponding to the missing data is stored in the missing cache queue, and the bus is requested for the missing data at the same time. After waiting for the data to be returned from the lower storage, the CPU is notified to re-execute the instruction;

[0046] The internal LR / SC consistency model solves atomic memory access instructions.

[0047] Also includes:

[0048] When the data needed by the core CPU of the SOC processor is missing in the cache, the CPU will not be blocked and wait for the data to be ready, but will put the instruction with unready data into the missing processing queue and continue to execute the next instruction. When the data is retrieved from the lower memory to the L1 cache, the instruction will be re-executed;

[0049] When the SOC processor core CPU modifies data and writes it back to the L1 Cache, the data in the L1 Cache is marked as dirty data. At the same time, when other CPUs in the SOC apply for access to the data, since the data is only updated in the local L1 Cache of the CPU that writes the data, the local L1 Cache of other CPUs does not have the latest copy of the data, and a consistency algorithm is needed to synchronize the data.

[0050] The missed operations are recorded in the cache miss queue, and the CPU is notified to re-execute the corresponding instructions after the data is retrieved from the L1 Cache, including:

[0051] Record the address of the missing instruction into the miss cache queue and notify the CPU to continue executing subsequent instructions;

[0052] At the same time, the address of the missing data is sent to the bus to notify the lower storage unit to transmit the corresponding data;

[0053] The required data is retrieved to the SRAM of the L1 Cache through the bus, and the previously stored missing instruction address is taken out from the missing cache queue to notify the CPU to execute the instruction again.

[0054] To maintain data consistency between multiple cores, different cores have different data permissions. The consistency protocol defines four different permissions: no local data, local data but only read permission, local data with read and write permissions, local data with read and write permissions and dirty data. Specifically, they include:

[0055] When the required data is not available locally and the current request is to read data, a request needs to be sent to the bus to read data from the remote end; when the data requested from the remote end is not marked as dirty data, the requested data is returned to the requesting end, and both the local and remote ends have the latest copies; when the data requested from the remote end is marked as dirty data, the dirty data needs to be written back to the lower-level memory first, and the data is returned to the local cache at the same time, and both the remote and local ends have the latest copies of the data;

[0056] When the required data is not available locally and the current request is to write data, a data request needs to be sent to the bus to read data from the remote end; when the data requested from the remote end is not marked as dirty data, a copy of the data is returned to the requesting end. After the local write operation, the local copy of the data is dirty data and the remote copy of the data is invalidated; when the data requested from the remote end is marked as dirty data, a copy of the data needs to be written back first and the data is returned to the requesting end. At this time, the remote data copy becomes a Branch or Trunk. After the requesting end writes data, the local data is marked as dirty data and the remote data is invalidated;

[0057] When there is a local copy of the data, it means that there is no dirty data in the local cache of all cores. When the data needs to be read, it is read directly through the local cache; when the data needs to be written, first determine whether the permissions corresponding to the local data are sufficient. If the permissions are sufficient, the data is written directly, otherwise the data permissions need to be upgraded before writing the data. At the same time, other core data are invalidated and the local data permissions are changed to Dirty.

[0058] The dirty data needs to be written back. There are two ways to write back. One is to write back the data during the consistency maintenance described in claim 3. The other is that the CPU actively writes back the dirty data, including:

[0059] When consistency maintenance involves dirty data, the data needs to be written back to the next level of storage while maintaining consistency;

[0060] When too much dirty data accumulates locally, the CPU will actively process all the dirty data in a pipeline at one time.

[0061] An independent cache ICache needs to be designed to provide instructions for the CPU fetch stage, including:

[0062] When the instruction fetch IF stage in the CPU pipeline needs the instruction corresponding to the program counter PC, the instruction corresponding to the corresponding address will be taken out from the ICache and returned to the CPU;

[0063] ICache only needs to provide data access to the CPU during the instruction fetch stage. The CPU does not return data to ICache. All data in ICache comes from the lower-level memory writing to ICache through the bus. Data that does not exist becomes dirty data after being written by the CPU. Therefore, there is no need to provide consistency maintenance and data write-back support for ICache.

[0064] Furthermore, ICache is designed as an 8-way set-associative dual-bank structure, with three storage structures, namely vb_array, tag_array, and data_array, which are used to store valid bits, tag data, and specific instruction data, respectively. Each valid bit of data only requires 1 bit to represent, and the size of vb_array is designed to be 64x8 bits; each tag has 20 bits of data, so the size of the tag is designed to be 64x8x20 bits; data_array is a storage structure for storing specific data, such as Figure 1 As shown in the figure, the design divided into two banks is used to speed up the data access delay. Each bank is divided into 8 single SRAMs. The corresponding SRAMs in each bank are combined into one channel. The size of each SRAM row is designed to be 64 bits. Four rows form a block in a bank, so the size of the SRAM is 64x4x8x2x64 bits.

[0065] Figure 2 The position indicated by the dotted line is the pipeline register. ICache is designed as a 2-stage pipeline, divided into 3 stages. Stage 0 is to accept the CPU request and the bus refill request. When the req_fire signal is valid, the cache starts the hit judgment logic, divides the address and transmits it to tag_array and data_array respectively; when the d_fire of the D channel of the bus is valid, it will enter the refill logic. The priority of the refill logic is higher than the CPU request logic, otherwise the missing request will be missed forever. The bus width is 128 bits, and the size of each refill is the size of a cache block 64B. Therefore, a block requires 4 cycles to refill the corresponding data into the replacement path given by the replacement algorithm. When the refill_cnt counter counts from 0 to 3, the corresponding tag will be written into tag_array and the corresponding bit in vb_array will be set to 1 when the transmission is completed. The invalidated signal indicates that the entire ICache is invalid. It is used in conjunction with the ifence instruction. The ifence instruction will limit the order before and after the execution of instructions, and will clear the ICache to avoid the influence of the previous instruction.

[0066] The first stage of the ICache pipeline will obtain the tag data and data data read from the SRAM, and compare the read 20x8 tag and valid bit flag with the tag requested by the CPU. If they are equal, it is a hit, and s1_hit is pulled high to enter the hit logic, otherwise it enters the cache miss logic.

[0067] The third stage of the ICache pipeline will return the data corresponding to the CPU or request the missing data from the bus. When it is a hit logic, it will be read from data_array and returned to the CPU; if it is a bit miss logic, the address of the missing data will be sent to the lower memory through the B channel of the bus to request the missing data, and the replacement algorithm will be used to generate the way memory that needs to be replaced and put the missing address into the register. After the data is returned from the bus, the corresponding data will be written into data_array and tag_array by replacing the way and the missing address.

[0068] An independent cache DCache needs to be designed to provide data access and cache for the SLU stage of the CPU, including:

[0069] When a load instruction is issued, the data corresponding to the requested address needs to be provided to the CPU. When a save instruction is executed, the corresponding data needs to be cached to the corresponding address, and the permission of the data in the DCache is set to Dirty.

[0070] Since the LSU module not only needs to access the DCache, but also needs to write data, which causes the data in the DCache to become dirty data, a consistency maintenance and write-back module needs to be added to the DCache. At the same time, in order to improve the performance of the CPU, when the data that the LSU needs to access is not in the DCache, the CPU will not enter a waiting state due to the lack of the data, but will instead switch to executing other instructions that are not related to the instruction. Therefore, a missing cache processing mechanism needs to be added.

[0071] Furthermore, DCache is designed as an 8-way set-associative single-bank structure, with three built-in caches, namely meta_array, tag_array, and data_array, which store permission data, tag data, and memory access data respectively. The cache has four permissions, namely Nothing, Branch, Trunk, and Dirty, which respectively indicate that there is no corresponding data in the cache, there is corresponding data in the cache but it can only be read but not written, there is corresponding data in the cache that can be read and written, and there is corresponding data in the cache and has been written by the CPU. Therefore, each block requires 2 bits of data to represent the corresponding permission. The size of meta_array is designed to be 2x8x64bits; the design of tag_array is consistent with that of ICache, which is designed to be 20x8x64 bits; data_array is a single-bank design, such as Figure 3 As shown, it consists of 8 SRAMs, each SRAM has a row of 128 bits, and 4 rows form a cache block. Therefore, the size of DCache is 128x8x4x64 bits, which is the same as the size in ICache.

[0072] Figure 4 The position indicated by the dotted line is the pipeline register. DCache is designed as a 5-stage pipeline, divided into 6 stages. The first two stages of the pipeline are used to process non-atomic operations, and the last three stages are mainly used to process atomic operations. There are 6 data streams in DCache, namely lsu_req, writeback, prober, prefetch, mshr_read, and replay. The s0 stage is mainly for data path selection, and then the address arbitrator module that needs to read the data will pass the address to the meta permission data storage and access module and the data data access module for permission and data reading.

[0073] In the s1 stage, meta information and tag information are obtained. In this stage, the meta and tag information can be used to determine whether the operation of req hits the cache. s1_tag_eq_way is an 8-bit one-hot signal generated by the hit logic module. The hit logic module compares the tag of req with the tag read from meta. When coh is valid, the corresponding bit of s1_tag_eq_way becomes 1. s1_tag_eq_way, s1_replay_way_en, s1_wb_way_en, s1_meta_read_way_en are all one-hot signals. The way_en select module will select one as s1_match_way according to the type of s1_type. At the same time, the LSU module will also pass in the branch prediction results in this stage. If the branch prediction is wrong, the execution of the instruction will be canceled, and the subsequent pipeline operations will not be performed to save energy.

[0074] In the s2 stage, the data read by data_array will be obtained. If it is the lsu_req data path, it will determine whether it is a hit. If it is a hit, the corresponding write will be executed or the read data will be returned to the LSU module. If the data is missing, the missing operation will be recorded in the MSHR unit, and the MSHR will send the address of the missing data to the bus, wait for the corresponding data to be returned by the master, and then record it in the corresponding cache, and notify the LSU to enter the replay data; if it is the replay data path, the data must be in the cache, and the corresponding information will be returned to the LSU unit in the s2 stage; if it is the prefetch data path, the address to be prefetched will be sent to the MSHR unit, and the bus will be requested to read data through the MSHR unit; if it is the writeback data path, the data to be written back to the master will be sent, and the permissions of the corresponding data will be changed at the same time; if it is the prober data path, writeback will be called to write the corresponding data to the bus, and the permissions of the corresponding data will be modified at the same time; if it is the mshr_read logic, the data that the MSHR unit needs to read will be sent to the MSHR module.

[0075] In the s2 stage, the atomic operation will also be judged. Before performing the atomic operation, the corresponding lock needs to be obtained. The lr / sc instruction is the process of obtaining the corresponding lock. LR (Load-Reserved) is a mutually exclusive read instruction. The instruction will be used to read a 32-bit data (in the decoding process, LR_W and LR_D are decoded into the same instruction, W indicates 4B alignment, D indicates 8B alignment) from the memory (the address is specified by the value of the rs1 register) and store it in the rsd register. SC (Load-Reserved) is a mutually exclusive write instruction, which is used to write a 32-bit data (in the decoding process, SC_W and SC_D are decoded into the same instruction, W indicates 4B alignment, D indicates 8B alignment) to the memory (the address is specified by the value of the rs1 register). The value of the data comes from the value in the rs2 register. The SC instruction may not be executed successfully. The SC instruction can only be executed successfully if the following conditions are met: 1. The LR and SC instructions access the same address in pairs; 2. No other operation between the LR and SC instructions has accessed the same address; 3. No interrupt exception occurs between the LR and SC instructions; 4. No MRET instruction is executed between the LR and SC instructions. The specific execution steps are: 1. Use the LR instruction to read the value in the lock; 2. Judge the read value. If the value in the lock is 1, it means that the lock is occupied by other cores. Continue to return to step 1 and repeat the reading. If the value in the lock is 0, it means that the current value in the lock is empty, and go to step 3; 3. Use SC to write 1 to the lock, try to lock it, and then judge the instruction result return. If the return result indicates that the mutually exclusive write instruction is executed successfully, it means that the lock is successful, otherwise it means that the lock fails. Since the bus is not locked between the first read and the second write, other cores may also access the lock, and other cores may find that the value in the lock is 0, and write the value 1 to the lock to try to lock it. However, the monitoring in the system will ensure that only the core that performs the exclusive write first will succeed, and the core that performs the exclusive write later will fail, thus ensuring that only one core can successfully lock the lock each time.

[0076] The writeback module is a writeback module, which is controlled by a state machine. The writeback state machine has five states: s_invalid, s_fill_buffer, s_lsu_release, s_active, and s_grant. Figure 5As shown. s_invalid is the initial state. When the fire signal of req is valid, the state machine is started and jumps to s_fill_buffer. At the same time, a data_req_cnt counter is initialized to 0 and acked is set to 0. In this state, s_fill_buffer reads the block pointed to by the req address into wb_buffer. wb_buffer is a 4x128 bits register because data is stored as 128 bits per row and 4 rows per block in sram. The read address of meta permission data is directly req_idx, but it should be noted that the read address of data is {req_idx, data_req_cnt[1:0]}. When the ready signal of the corresponding arbitrator is pulled high, the ready signal of wb_io_data_req will be valid. When the ready signal of the arbitrator is 1, it means that the corresponding data has been received, that is, the data has been successfully read from the memory. At this time, the value of data_req_cnt + 1 indicates that the next row of data is read. It should be noted that wb_buffer needs to be assigned two clock cycles, which means that it takes two clock cycles from reading the address into the memory to the data reaching the output. Here, it is necessary to wait until r2_data_req_fire is 1 to write wb_buffer[r2_data_cnt] as the data of io_data_resp. When wb_buffer is cached, it enters the s_lsu_release state and assigns data_req_cnt to 0. In the s_lsu_release state, the data of wb_buffer has been cached as the data of req. At this time, the data is converted into a TLBundleC structure through the ProbeAck_data function and handed over to the output io_lsu_release. When the data of io_lsu_release is correctly received, it enters the s_active state. In the s_active state, data is transferred to the bus. According to whether it is automatic or passive, the Release_data or ProbeAck_data function is selected to convert the data into TLBundleC type data and transfer it to the bus. At the beginning, the value of data_req_cnt is 0. Every time the bus successfully receives a data, the value of data_req_cnt is +1. When the transmission is completed, it enters the s_grant state or s_invalid state according to whether it is an active write back. Note that the mem_grant signal can also be received in this state. After receiving the signal, set acked to 1, indicating that it can end directly.Wait for the io_mem_grant signal in the s_grant state. When the grant signal is received, set acked to 1. The process ends when acked is 1.

[0077] The prober module has 11 states, namely s_invalid, s_meta_read, s_meta_resp, s_mshr_req, s_mshr_resp, s_lsu_release, s_release, s_writeback_req, s_writeback_resp, s_meta_write, s_meta_write_resp, and their state transitions Figure 6As shown. s_invalid is the initial state. When channel B requests probe, the state jumps to the s_meta_read state. The s_meta_read state is to read the permission and tag information of the requested address. At this time, the valid signal of the output port meta_read is pulled high, and the address message of the req request is assigned to the meta_read structure, waiting for the metaReadArb arbitrator to process the request. When the request is processed and the feedback ready signal is pulled high, the state jumps to the meta_resp state. The s_meta_resp state is the state of waiting for meta and tag data to be read. After one cycle, it directly jumps to the s_mshr_req state. In the s_mshr_req state, the data in the old_coh register has been updated to the meta permission and tag of the requested data, and the way_en register is valid. The bitwise XOR can be used to determine whether the requested probe block is in the cache, that is, to obtain the valid value of the tag_matches signal. The old_coh and Nothing states are selected to update the original state by checking whether tag_matches is 1. The onProbe function obtains the new state new_coh, whether it is the dirty bit, and the param parameter to be returned based on the req request and the original state. The s_lsu_lsu_release state converts the data into a BundleC structure and hands it over to the lsu_release interface. When the data is successfully received by the lsu end, it jumps to the s_release state. In the s_release state, rep_valid is valid, just like s_lsu_release. The data is converted into a BundleC structure and handed over to rep. When the data is successfully received by the Bus, it jumps to the s_meta_write or s_invalid state according to whether the data currently required to be probed is in the cache.In the s_writeback_req state, if the data exists in the cache, the corresponding block needs to be written back. In this state, the writeback req information is submitted to the writeback arbitrator and received by the writeback module, and then the s_writeback_resp state is entered to wait for the writeback to be completed; in the s_writeback_resp state, it is necessary to wait for io_wb_req_ready to be 1 to jump to the s_meta_write state. The io_wb_req_ready signal is connected to the wbArb arbitrator and finally connected to the req interface of the writeback module. The ready signal of the writeback req interface is 1 only when the s_invalid signal is on. Since the previous state s_writeback_rep will cause the writeback module to jump out of the s_invalid state, it is necessary to wait for r The eady signal is 1, which is equivalent to waiting for the writeback module to return to the s_invalid state, that is, the function of this state is to wait for the writeback module to complete a write-back operation; in the s_meta_write state, the req information and new_coh are updated to the io_meta_write port, and after waiting for the meta write module to receive the data, it enters the s_meta_write_resp. The s_invalid state is not entered directly here because writing requires a cycle of time. In order to ensure the smooth writing of data, s_meta_write_resp is added; in the s_meta_write_resp state, the function of this state is to wait for a cycle to write the corresponding data to the permission memory and tag memory.

[0078] Obviously, the above embodiments are merely examples for clear explanation and are not intended to limit the implementation methods. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the implementation methods here. The obvious changes or modifications derived from these are still within the protection scope of the invention.

Claims

1. A non-blocking L1 Cache in a multi-core SOC, wherein the L1 Cache includes two circuit modules, an ICache and a DCache, and is characterized in that: The ICache circuit module is designed as an 8-way set-associative dual-bank SRAM to provide data access for the CPU instruction fetch stage. The DCache circuit module is designed as an 8-way set-associative single-bank SRAM to provide data access for the CPU LSU instruction fetch stage. In addition, it includes: When the data needed by the core CPU of the SOC processor is missing in the cache, the CPU will not be blocked. After waiting for the data to be ready, the instruction with unready data will be put into the missing processing queue and the next instruction will be executed. When the data is retrieved from the lower memory to the L1 cache, the instruction will be re-executed. When the core CPU of the SOC processor modifies data and writes it back to the L1 Cache, the data in the L1 Cache is marked as dirty data. At the same time, when other CPUs in the SOC apply to access the dirty data, since the dirty data is only updated in the local L1 Cache of the CPU that writes the data, the local L1 Cache of other CPUs does not have the latest copy of the dirty data, and the consistency algorithm needs to be used to synchronize the dirty data; To maintain data consistency between multi-core SOCs, different cores will have different data permissions. The consistency protocol defines four different permissions: no local data, local data but only read permission, local data with read and write permissions, local data with read and write permissions and dirty data, including: When the required data is not available locally and the current request is to read data, a request needs to be sent to the bus to read data from the remote end; when the data requested from the remote end is not marked as dirty data, the requested data is returned to the requesting end, and both the local and remote ends have the latest copies; when the data requested from the remote end is marked as dirty data, the dirty data needs to be written back to the lower-level memory first, and the data is returned to the local cache at the same time, and both the remote and local ends have the latest copies of the data; When the required data is not available locally and the current request is to write data, a data request needs to be sent to the bus to read data from the remote end; when the data requested from the remote end is not marked as dirty data, a copy of the data is returned to the requesting end. After the local write operation is performed, the local copy of the data is dirty data and the remote copy of the data is invalidated; when the data requested from the remote end is marked as dirty data, a copy of the data needs to be written back first and the data is returned to the requesting end. At this time, the remote data copy becomes a branch or a trunk. After the requesting end writes data, the local data is marked as dirty data and the remote data is invalidated. When there is a local copy of the data, it means that there is no dirty data in the local cache of all cores. When the data needs to be read, it is read directly through the local cache; when the data needs to be written, first determine whether the permissions corresponding to the local data are sufficient. If the permissions are sufficient, the data is written directly. Otherwise, the data permissions need to be upgraded before writing the data. At the same time, other core data are invalidated and the local data permissions are changed to Dirty.

2. The non-blocking L1 Cache in a multi-core SOC according to claim 1, characterized in that: The missed operations are recorded in the cache miss queue, and the CPU is notified to re-execute the corresponding instructions after the data is retrieved from the L1 Cache, including: Record the address of the missing instruction into the miss cache queue and notify the CPU to continue executing subsequent instructions; At the same time, the address of the missing data is sent to the bus to notify the lower storage unit to transmit the corresponding data; The required data is retrieved to the SRAM of the L1 Cache through the bus, and the previously stored missing instruction address is taken out from the missing cache queue to notify the CPU to execute the instruction again.

3. The non-blocking L1 Cache in a multi-core SOC according to claim 2, characterized in that: The dirty data needs to be written back. There are two ways to write back. One is to write back the data when maintaining the data consistency between the multi-core SOCs. The other is that the CPU actively writes back the dirty data, including: When consistency maintenance involves dirty data, the data needs to be written back to the next level of storage while maintaining consistency; When too much dirty data accumulates locally, the CPU will actively process all the dirty data in a pipeline at one time.

4. The non-blocking L1 Cache in a multi-core SOC according to claim 3, characterized in that: An independent cache ICache needs to be designed to provide instructions for the CPU fetch stage, including: When the instruction fetch IF stage in the CPU pipeline needs the instruction corresponding to the program counter PC, the instruction corresponding to the corresponding address will be taken out from the ICache and returned to the CPU; ICache only needs to provide data access to the CPU during the instruction fetch stage. The CPU does not return data to ICache. All data in ICache comes from the lower-level memory writing to ICache through the bus. Data that does not exist becomes dirty data after being written by the CPU. Therefore, there is no need to provide consistency maintenance and data write-back support for ICache.

5. The non-blocking L1 Cache in a multi-core SOC according to claim 3, characterized in that: An independent cache DCache needs to be designed to provide data access and cache for the SLU stage of the CPU, including: When a load instruction is issued, the data corresponding to the requested address needs to be provided to the CPU. When a save instruction is executed, the corresponding data needs to be cached to the corresponding address, and the permission of the data in the DCache is set to Dirty. Since the LSU module not only needs to access the DCache, but also needs to write data, which causes the data in the DCache to become dirty data, a consistency maintenance and write-back module needs to be added to the DCache. At the same time, in order to improve the performance of the CPU, when the data that the LSU needs to access is not in the DCache, the CPU will not enter a waiting state due to the lack of the data, but will instead execute other instructions that are not related to the instruction. Therefore, a missing cache processing mechanism needs to be added.

Images