System and method for managing cache replacement

Abstract

A method of managing load units of executable instructions between internal memory in a microcontroller having a plurality of bus masters and a non-volatile memory device external to the microcontroller. A copy of the load unit is loaded from the external memory device into the internal memory for use by a corresponding bus master. Each load unit is associated with a corresponding load entity queue, and each load entity queue is associated with a corresponding one of the plurality of bus masters. Each load entity queue selects an eviction candidate from the associated copy of the load unit currently loaded in the internal memory. Information identifying the eviction candidate for each load entity queue is broadcast to all load entity queues. If none of the load entity queues veto use of the eviction candidate, the eviction candidate is added to a set of managed eviction candidates.

Description

Technical Field

[0001] The field of this invention relates to a memory system and a method for memory management therein, which supports software execution in embedded information systems such as those in vehicles (in an automotive environment). Background Technology

[0002] Computer systems typically benefit from tiered memory designs, where (at least partial) copies of memory contents can be stored (i.e., cached) at different levels within a memory hierarchy. Hardware supporting different memory levels generally has varying capacities, costs, and access times. Generally, faster and smaller memory circuitry is located closer to the processor core or other processing elements within the system and acts as a cache. Other types of memory storage devices in a processing system may be larger and cheaper, but may also be relatively slower compared to those acting as caches.

[0003] Currently, embedded processing systems used in vehicles support application images up to 16 megabytes in size, thereby accessing instruction caches ranging from 4 to 12 megabytes. In the coming years, the amount of data and instructions processed is likely to increase as applications require different amounts of information. Summary of the Invention

[0004] According to one embodiment, a processing system includes:

[0005] Microcontroller devices;

[0006] An external memory device located outside the microcontroller device, the external memory device being coupled to the microcontroller device;

[0007] The microcontroller device includes:

[0008] The bus master, configured to execute application code;

[0009] A random access memory (RAM) device, which is internal to the microcontroller device and coupled to the bus master via interconnects, the RAM device including a system memory portion and an instruction portion, the instruction portion being configured to store copies of a subset of load units from the external memory device for use by the application code, wherein the load units include executable instructions and / or data and are associated with a corresponding one in the application code;

[0010] A cache controller device coupled to the random access memory and the external memory device and including a load entity queue, each of the load entity queue being associated with one of the bus masters, the cache controller device being configured to:

[0011] Manage a group of expelled candidates;

[0012] Periodically select eviction candidates from the copies of the loading units in the instruction section;

[0013] If at least one entity in the loading queue rejects the eviction candidate, then the eviction candidate is discarded; and

[0014] Replace the eviction candidate in the instruction section with a copy of the requested loaded unit.

[0015] According to some implementations, each of the loading entity queues is configured to request the loading of a loading unit, and periodically selects eviction candidates to be included in the set of managed eviction candidates from the copies of the loading units in the instruction portion associated with the loading entity queue.

[0016] According to some implementations, the cache controller further includes:

[0017] An address mapping device capable of operating to manage the instruction portion of the internal memory, including tracking the memory area occupied by copies of a subset of the loading units and the available memory area within the instruction portion not occupied by copies of a subset of the loading units.

[0018] According to some implementations, the cache controller further includes:

[0019] A load manager device is configured to process requests to load the load unit from the external memory device and to query, in the address mapping device, an available storage location within the instruction portion that is large enough to store a copy of at least a portion of the requested load unit.

[0020] According to some embodiments, the processing system further includes:

[0021] A cache replacement manager device, coupled to the load entity queue and the address mapping device, wherein...

[0022] When there is insufficient storage space to store a complete copy of the requested loaded unit, the cache replacement manager device selects one of the managed eviction candidates from the set of managed eviction candidates according to the request of the address mapping device, and verifies the selected eviction candidate.

[0023] The address mapping device responds to the query of the load manager device by: providing the available storage location when sufficient storage space is available, and repeatedly requesting additional eviction candidates from the cache replacement manager device and evictioning the additional eviction candidates from the instruction section until sufficient storage space in the instruction section is available for a complete copy of the requested load unit.

[0024] According to some implementations, the cache controller device is further configured to:

[0025] Broadcast the eviction candidates to the loading entity queue;

[0026] When an acknowledgment signal is received but no rejection response is received from any of the loaded entity queues, the eviction candidate is verified.

[0027] According to some implementations, when the corresponding loading entity queue does not currently need the loading unit corresponding to the eviction candidate, the corresponding loading entity queue agrees to use the broadcast eviction candidate.

[0028] According to some implementations, each load entity queue is associated with a specific bus master, and each load entity queue manages only the load units associated with the application code executed by the corresponding bus master.

[0029] According to some implementations, when a loading unit satisfies at least one of the following conditions: a) the loading unit is currently used by the bus master associated with the loading entity queue, b) the loading unit has recently been used by the bus master associated with the loading entity queue, and c) the loading entity queue knows that the loading unit will be used by the bus master associated with the loading entity queue in the foreseeable future, the corresponding loading entity queue identifies a copy of the loading unit as currently needed.

[0030] According to some implementations, each load cell is specified by an address range corresponding to an address range in the external memory, and at least two of the load cells have different lengths.

[0031] According to one embodiment, a method is provided for managing a loading unit for executable instructions between internal memory in a microcontroller having multiple bus masters and a non-volatile memory device external to the microcontroller. The method includes:

[0032] A copy of the loading unit is loaded from the external memory device into the internal memory for use by the corresponding bus master. Each loading unit is associated with a corresponding loading entity queue, and each loading entity queue is associated with a corresponding one of the plurality of bus masters.

[0033] Eviction candidates are selected from the associated copies of the load units currently loaded in the internal memory through each load entity queue;

[0034] Broadcast the information identifying the eviction candidates for each loaded entity queue to all loaded entity queues; and

[0035] If no loading entity queue rejects the use of the eviction candidate, then the eviction candidate is added to a group of managed eviction candidates.

[0036] According to some implementations, the method further includes:

[0037] Periodically select eviction candidates from the copies of the loading units associated with each loading entity queue in the internal memory;

[0038] If at least one entity in the loading queue rejects the eviction candidate, then the eviction candidate is discarded; and

[0039] Replace the eviction candidate in the internal memory with a copy of the requested loaded unit.

[0040] According to some implementations, if a copy of the loading unit is being used by one of the loading entities in the loading entity queue, the loading entity queue rejects the eviction candidate.

[0041] According to some implementations, the method further includes approving the eviction candidate when all the loading entity queues determine at least one of the following: a) the eviction candidate does not correspond to a currently used copy of the loading unit, and b) the copy of the loading unit corresponding to the eviction candidate has not been used recently.

[0042] According to some embodiments, the method further includes managing the copies of the loading unit in the internal memory by tracking the storage area occupied by each copy of the loading unit and the available storage area in the internal memory not occupied by the copies of the loading unit, wherein at least two of the copies of the loading unit have different lengths.

[0043] According to some embodiments, the method further includes: querying an available storage location within the internal memory, the storage location being large enough to store a copy of the requested load unit or a portion thereof.

[0044] According to some implementations, the method further includes:

[0045] The query is responded to by: providing the available storage location when sufficient storage space is available, and repeatedly requesting additional eviction candidates until sufficient storage space in the instruction section is available for the copy of the loading unit.

[0046] According to some implementations, the method further includes:

[0047] When an acknowledgment signal is received but no rejection response is received from any of the loaded entity queues, the eviction candidate is verified.

[0048] According to some implementations, when the corresponding loading entity queue does not currently require the copy of the loading unit associated with the eviction candidate, the broadcast eviction candidate is agreed to be used.

[0049] According to some implementations, each load entity queue is associated with a specific bus master, and each load entity queue manages only the load units associated with the application code executed by the corresponding bus master. Attached Figure Description

[0050] The invention can be better understood by referring to the accompanying drawings, which will enable those skilled in the art to understand the various objects, features and advantages of the invention.

[0051] Figure 1 The timeline for selecting cache eviction candidates according to a selected embodiment of the present invention is shown.

[0052] Figure 2 A block diagram of a processing system according to a selected embodiment of the present invention is shown.

[0053] Figure 3 This illustrates the management process performed by the load entity queue in the cache controller according to the selected embodiment. Figure 2 The flowchart of the function for eviction of cache candidates in the processing system.

[0054] Figure 4 This illustrates the management performed by the cache replacement manager in the cache controller according to the selected embodiment. Figure 2 The flowchart of the function for handling cache eviction candidates in the system.

[0055] Figure 5 This illustrates the management performed by the load manager and address mapping device in the cache controller according to the selected embodiment. Figure 2 The flowchart of the function for handling cache eviction candidates in the system.

[0056] Unless otherwise specified, the same reference numerals are used in different figures to indicate similar items. Figures are not necessarily drawn to scale. Detailed Implementation

[0057] Embodiments of systems and methods for managing cache replacement processing of variable-sized load units that store executable instructions and constant data are disclosed. These systems and methods manage the loading of instructions and data from external memory devices to buffered memory such as random access memory (RAM) within the microcontroller. External memory devices provide a larger storage area for the currently running application than the bufferable storage area within the microcontroller's internal memory. The ability to handle variable-sized load units avoids unnecessary impact on application code and load bandwidth. Cache operations support the execution of multiple applications within the microcontroller through multiple processor cores that can use more than one instance of the same or different operating systems, and other types of bus masters that access instructions or constant data in memory. The systems and methods disclosed herein are implemented in a cache control subsystem, also referred to as the Operating System Aware Task Cache (OTC).

[0058] Unlike known processor cache arrangements that limit the size of load units for cache memory to a single size, variable-sized load units are supported by the cache management unit disclosed herein via decoupled load requests and cache eviction operations. Decoupling requests and eviction operations addresses a complexity of variable-sized load units by either eviction of multiple load units to make room for larger load units, or conversely, by loading multiple smaller units into the free space created by eviction of larger load units. In the case of a larger load unit request, more than one eviction candidate is selected, thus forcing the eviction of multiple load units to provide sufficient space. Multiple candidates must be properly managed before practical use, as a good eviction candidate at time X may be an unsuitable candidate at time X+Y. The complexity of managing multiple eviction candidates is significantly higher when cache contents are shared among multiple bus masters (e.g., processor cores) that execute different instructions in different load units within the cache.

[0059] Decoupling eviction and request operations can further allow for optimization of cache behavior. For example, to optimize the contents of a large cache, the most valuable data elements to be kept in memory can be identified. This type of optimization requires identifying one or more suitable eviction candidates in advance, which, as with traditional instruction caches, is not possible when identifying replacement candidates on demand.

[0060] As mentioned above, external memory can store more than one image, for example, to support over-the-air (OTA) updates of images, where one image holds the instructions and constant data of an application running concurrently within the microcontroller. Even if sufficient internal memory were provided concurrently in the internal RAM of a typical MCU to store all the instructions and constant data for a single image, in addition to the RAM required for the application data, it could still result in excessive costs due to RAM size requirements. Instructions for these applications are copied from external non-volatile memory and loaded into internal memory before they can be executed in an MCU that does not use non-volatile memory. A smart cache controller loads only a subset of the instructions and constant data currently being used / required by the application, helping to reduce the corresponding internal memory size required for this purpose. This type of partial buffering requires instructions to be loaded in advance to ensure their timely availability, unlike traditional caches that perform on-demand loading.

[0061] While external non-volatile memory can be significantly larger than internal memory, its access is typically much slower, especially for non-volatile memory in embedded systems suited to automotive environments. This can be further complicated in multi-core systems when multiple processor cores want to access instruction memory concurrently. Given the potentially limited performance of internal memory, this issue is evident in the need for L1 / L2 processor caches in today's embedded systems. Any slower access poses a challenge to the timing requirements of operating systems that must perform tasks in real time, particularly in embedded systems commonly found in the automotive field that must adhere to very strict real-time conditions. For example, when implementing braking, airbag, or powertrain applications, it may be necessary to react appropriately to events within milliseconds or microseconds. While preloading instructions from external memory into internal memory before running tasks that actually use the instructions can address this issue, it may be too late when bandwidth is insufficient for loading. Such preloading can be avoided when the required instructions are already in the cache (because they have been loaded earlier and will not be evicted from then on). This makes the proper management of cache replacement policies and cache eviction candidates a primary task of the cache controller element.

[0062] As previously mentioned, to accommodate variable-sized load units, a single new load unit may need to replace one or more load units already stored in internal memory. A single replaced load unit provides space for one or more new load units. Therefore, a single cache or load request may not trigger any event (when there is sufficient free space), a single (when the replaced load unit provides enough space for the new load unit), or multiple cache replacement operations (otherwise). These replacement operations are further termed "eviction" because there is no actual replacement of an earlier load unit by another load unit; rather, the load unit is evicted to make room for storing instructions later from another load unit that is being loaded. Since there may be multiple such load units that need to be evicted after a single load request, the main issue is the proper management of potential candidates for eviction. Otherwise, the time and effort spent searching for new candidates for eviction could create another unnecessary delay for any load operation that requires free space.

[0063] Figure 1 This illustrates some aspects of identifying eviction candidates and the time required for eviction. Events 111, 112, 113, 114, 115, and 116 depict the times when load units A111, B112, C113, D114, E115, and F116 are identified as eviction candidates. Event 130 depicts the time when it is identified that new load units need to be evicted. The arrows below timeline 100 depict the time spans for which the corresponding load units are needed, with arrow 121 depicting the time span for load unit A, arrow 122 depicting the time span for load unit B, arrow 123 depicting the time span for load unit C, and arrow 124 depicting the time span for load unit D. Here, the term "needs" refers to knowledge that the cache of the corresponding load unit is currently in use or may be used in the foreseeable future. Load units A, B, and D are needed at event 130, therefore these load units cannot be used for eviction. When identifying the need for eviction, the earlier selected eviction candidate can be disabled based on the need for the candidate at event 130.

[0064] Figure 1 Another compromise described relates to the management of loading unit C, which is a candidate for eviction. Loading unit C is needed during the time span in which it is identified as candidate eviction 113, but is no longer needed at event 130. When event 130 occurs, eviction candidates that were determined to be needed during their storage period can be discarded to reduce the number of available candidates.

[0065] Internal memory used for OTC caching is typically shared among multiple requesters of instructions and constant data, which are often implemented within the embedded system previously referred to as cache users as processor cores or other bus master types (e.g., DMA engines, coprocessors, or specific processing elements with bus master capabilities). Load requests supporting these cache users are preferably handled by a set of load entity queues, one of which supports the associated cache users and the load requests required for this activity. Each load entity queue may have specific preferences for selecting load units for cache replacement operations to reflect the specific needs of different applications and the different operating systems that ultimately manage said applications.

[0066] When sharing code between applications (e.g., in the case of shared libraries or a set of common constants) or between tasks of the operating system executing on multiple processor cores implemented within an MCU (e.g., common functionality shared by multiple tasks of the operating system), it is desirable to share load units managed by these load entity queues. Such code sharing may lead to conflicts in the operating conditions of the shared cache used by these cache users; for example, a load entity queue may identify the need for load units (to be loaded or held in cache memory) selected for eviction by another load entity queue. In this context, the load unit may be referred to as “required” when a) the load unit is a load unit containing the currently executing instruction, b) the load unit is a set of L load unit instances containing known or assumed instructions to be executed (these instructions may already be in the cache, or requested or scheduled to be loaded), c) the load unit is a load unit containing instructions that may be in the scheduling stack of the current function (in a set of N recently used load units), or e) the load unit is in another set of M load unit instances marked as locked for later use by the software (where L, M, and N are reasonably small numbers, such as 1-32, reflecting a finite set of load unit elements in the hardware elements that can be recorded in the load entity queue).

[0067] Figure 2A block diagram of a processing system 200 according to a selected embodiment of the present invention is shown. The processing system includes an operating system task-aware cache (OTC) subsystem for scheduling operations with variable-sized load units to be executed within the processing system 200. The processing system 200 includes a microcontroller 201 having two or more bus masters, such as processor cores 202, 204, 206, and other bus masters, such as direct memory access bus master 207 and / or other suitable bus masters. Processor cores 202, 204, 206 may use their own dedicated cache devices. In the illustrated embodiment, processor core 204 is not coupled to a dedicated cache, processor core 202 is coupled to a single dedicated cache 208, and processor core 206 is coupled to a hierarchy of dedicated caches 210, 212. Dedicated caches 208, 210, 212 may store data and instructions typically used by the respective processor cores 202, 206 and typically located near the processor cores 202, 206. In addition to the embodiments of the OTC cache subsystem disclosed herein, caches 208, 210, and 212 are optional and available.

[0068] Dedicated caches 208, 210, and 212 are typically located near their associated processor cores 202 and 206 and attempt to avoid latency issues that arise when processor cores 202 and 206 communicate with other devices within the microcontroller 201 (e.g., internal memory 216). Dedicated caches 208, 210, and 212 perform on-demand loading and operation independently of the OTC controller 224, which uses a predictive mechanism and internal memory 216 as memory to avoid latency and bandwidth problems when accessing external memory 234.

[0069] Bus masters 202, 204, 206, 207 and other interconnects and peripheral devices (not shown) are operatively coupled to interconnect 214, which may be a single interconnect or a specific set of interconnects. Interconnect 214 couples bus masters 202, 204, 206, 207 to communicate with bus slaves in response to access requests. Examples of bus slaves may include internal memory device 216 and peripheral devices represented by P0241 and P1242, which may be connected to interconnect 214 via peripheral bridge 240.

[0070] Internal memory device 216 may include multiple memory blocks, which may be organized in groups of random access memory (RAM) to allow multiple bus masters 202, 204, 206, 207 to concurrently access different memory groups. Internal memory device 216 provides storage areas for two functions: i) a first portion designated as system memory 222, which stores data of applications executing within processing system 200; and ii) a second portion designated as instruction cache 218, which holds instructions and constant data of the application in a structure called load unit 220. The portions for instruction cache 218 and system memory 222 may span multiple groups, and the contents of a group may be used by both portions; the portions for instruction cache 218 and system memory 222 are independent of any group.

[0071] Loading unit 220 contains copies of instructions and constant data associated with the corresponding loading unit 260 of the application within image 250 in external memory 234. For example, a tabular format containing relevant attributes of each loading unit 260 may be used to specify the corresponding information about the loading unit 260 of image 250. These relevant attributes may be stored separately from the instructions and constant data contained within the loading unit 260 in metadata (not shown). The metadata may alternatively be stored in different locations within external memory 234.

[0072] The microcontroller 201 further includes an OTC controller 224, which includes one or more load entity queues 226, a load manager 228, an address map 245, and a cache replacement manager 230, as well as other components not shown. Components of the OTC controller 224 may be implemented as separate units interacting with other components also separately implemented to provide the functionality of the OTC controller 224. The OTC controller 224 is operatively coupled to interconnect 214 via one or more register interfaces 225, 227 as a peripheral and / or bus master to access other bus subjects, such as internal memory 216. Alternatively, one or more components of the OTC controller 224 may be directly coupled to internal memory 216 via direct connection 223 to access internal memory 216. The OTC controller 224 (or the load manager 228 when implemented separately) may be coupled to external memory 234 via interface 233.

[0073] Each instance of load entity queue 226 supports access requests from associated bus masters 202, 204, 206, and 207. In addition to the common registers of OTC controller 224, load entity queue 226 may also use a dedicated set of control and status registers. Both the dedicated register set and the common register set can be accessed from interconnect 214 via register interfaces 225 and 227. Each load entity queue 226 is further coupled to cache replacement manager 230 and load manager 228. Load entity queue 226 uses the interface to load manager 228 to request the loading of load unit 260 from external memory 234.

[0074] During the processing of loading unit 260, loading entity queue 226 may store loading unit information 232 to identify relevant information about at least one loading unit 260 currently managed by the corresponding loading entity queue 226. The relevant loading unit information 232 may be metadata reflecting information about a subset of loading units 260 contained in image 250. The metadata of loading unit 260 may be stored together with or within image 250 in external memory 234, and may be temporarily loaded into internal memory 216. Loading unit information 232 associated with loading units 260 managed by onboard entity queue 226 may be read from internal memory 216 via bus master interface 227 or via direct connection 223 between internal memory 216 and OTC controller 224. In other embodiments, loading unit information 232 may be stored in other locations within OTC controller 224.

[0075] Two or more different types of load entity queues 226 can be implemented. A first type of load entity queue 226 can provide all the functionality required for the most complex type of bus master, typically processor cores 202, 204, and 206. Other types of load entity queues 226 may provide only a subset or simplified form of functionality to match the specific needs of a particular bus master, or to provide a cost-effective implementation for bus masters implementing significantly fewer functions. For simplicity, this type, which does not implement the full load entity queue functionally, is referred to as a “simplified” load entity queue 226.

[0076] Load manager 228 is coupled to communicate directly with load entity queue 226, address mapping device 245, and cache replacement manager 230. Load manager 228 may also provide a register interface (not shown) to interconnect 214 for software interaction and access internal memory 216 via interconnect 229 or direct connection 223 to internal memory 216 using a bus master interface. Load manager 228 communicates with external memory device 234 via interface 233 to request the contents of load unit 260 from external memory 234, which is stored as temporary load unit 220 in the instruction cache portion 218 of internal memory 216.

[0077] Another element shown in the OTC controller 224 is an address mapping device 245, which is connected to the load manager 228 and the cache replacement manager 230. When the load manager 228 wants to store the first load unit 260 or a portion of such load units in the instruction cache 218, the address mapping device 245 queries a free storage location at least once. When there is sufficient free storage space available in the instruction cache 218, the address mapping device 245 provides corresponding information about the space available to the load manager 228. When there is insufficient free storage space available, the address mapping device 245 provides an eviction request to the cache replacement manager 230. Upon receiving such an eviction request, the cache replacement manager 230 provides information about the temporary load unit 220 selected for eviction. The location of the load unit 220 selected for eviction is used by the address mapping device 245 to free up the storage space used by the selected load unit 220. The free storage space can then be used to store the instructions and constant data of the first load unit 260 as a temporary load unit 220 in the instruction cache 218. By providing this function, the address mapping device 245 manages the use of free storage space within the instruction cache 218 to store a copy of the first loading unit 260 as a temporary loading unit 220 and release the storage space when the temporary loading unit 220 is evicted.

[0078] The cache replacement manager 230 is coupled to the address mapping device 245 and the load entity queue 226. When the address mapping device 245 determines that there is insufficient storage space in the instruction cache 218 for a new temporary load unit 220, the address mapping device 245 queries the cache replacement manager 230. This query can be triggered when the load manager 228 processes a load request that requires storage for the temporary load unit 220. An event 230 occurs requiring the eviction of one or more temporary load units 220. Figure 2 When ), the corresponding query operation is triggered.

[0079] To enable rapid response to eviction requests, cache replacement manager 230 can store information about a set of managed eviction candidates 236, processing the candidates when an eviction request is identified. Temporary load units 220 to be evicted from instruction cache 218 can be identified based on specified criteria such as priority or other suitable standards. The eviction process itself can be managed by address mapping device 245, as previously described herein. A set of managed eviction candidates 236 can be generated based on the eviction candidates identified by load entity queue 226. Individual identification processing ensures that each load entity queue 226 provides only eviction candidates belonging to the set of temporary load units 220 managed by the corresponding load entity queue 226. This allows for dedicated management of a subset of temporary load units 220 by only those elements of OTC controller 224 responsible for managing the subset. Independent management of load units 260 allows for appropriate data separation and interference freedom between related operations and permits independent processing. It can also ensure fair processing of load unit eviction procedures. For the purpose of selecting candidates to be removed, any loading entity queue 226 may use the corresponding loading unit information 232.

[0080] External memory device 234 may be implemented using non-volatile memory or other suitable types of memory devices. External memory device 234 stores at least one image 250, which includes instructions and constant data associated with at least one application program to be executed by processor cores 202, 204, 206 implemented within microcontroller 201. At least one image 250 is configured as one or more load units 260, which can be used as a single unit when instructions and constant data are loaded from external memory 234. For example, image 250 can be configured as load unit 260 by storing additional metadata (data about data) associated with load unit 260 in external memory 234. The metadata may be stored separately (not shown) or as part of image 250. Load manager 228 accesses external memory 234 via interface 232 for loading load units 260 and writing the instructions and constant data included in load units 260 into corresponding temporary load units 220 within instruction cache 218. Write operations from external memory 234 to instruction cache 218 can be performed using write path 229 via interconnect 214 or direct connection 223 to internal memory 216.

[0081] The microcontroller 201 and the external memory device 234 are implemented on two different semiconductor devices, which may be within a single package or in different packages. Correspondingly, the interface 233 between the two semiconductor devices may be a connector within a package or between two packages.

[0082] The size of the internal memory device 216 may be limited compared to the size of the external memory device 234. The external memory device 234 can store multiple images 250, and each image 250 can store instructions and data for one or more applications executed by processor cores 202, 204, and 206. The execution of the applications is typically controlled by an operating system, which in many cases needs to adhere to strict real-time conditions and is therefore called a Real-Time Operating System (RTOS). Applications controlled by an RTOS can use tasks to identify their execution units. Although the images 250 storing one or more applications executed by the microcontroller 201 can be entirely stored in the external memory device 234, this image can be divided into contiguous executable code segments called load units 260. A temporary copy 220 of the contents of the load unit 260 (which stores instructions and constant data) can be loaded into the instruction cache 218 for use by the corresponding processor cores 202, 204, 206, or other bus masters 207. Therefore, a load unit 260 is a segment of instructions and constant data reflecting one or more complete software functions within a contiguous address range. The temporary loading unit 220 loaded into internal memory 216 is operable to be executed or otherwise processed by processor cores 202, 204, 206, or used by another bus master 207 within microcontroller 201.

[0083] Loading units 260 can be specified by segmenting the application's code and instructions within image 250 along a set of contiguous address ranges along functional boundaries. These functionalities can be associated with tasks or shared by multiple tasks supported by at least one instance of a real-time operating system. Information about loading units 260 can be specified in metadata and can be generated manually during software development processes or by tools or toolstreams that automate the relevant generation processes. Size limitations can be imposed on loading units 260, for example, a minimum size of 1 kilobyte and a maximum size of 63 kilobytes. No other limitations are required (e.g., address alignment of start or end addresses). A preferred order for loading a set of loading units 260 can be defined by a loading order also specified in the metadata. Any loading order can include any number of loading units 260.

[0084] Bus masters 202, 204, 206, 207 and OTC controller 224 can execute their respective operations concurrently and independently of each other. For example, loading instructions and constant data from external memory device 234 can be performed independently of the processing executed by bus masters 202, 204, 206, 207. This processing can be software executed by processor cores 202, 204, 206, which itself can be multiple software threads executing on multiple processor cores 202, 204, 206, or other processing executed by any other bus master 207. The potential concurrency of operations depends on the corresponding hardware performing such operations. Access to external memory device 234 can be performed concurrently with any other operation. Potential conflicts may arise when accessing internal memory 216. Here, (e.g., when writing the contents of a load cell read from external memory) a conflict between an access by one of the bus masters and an access by OTC controller 224 is possible. However, for example, by using multi-port memory or by using a specific memory architecture such as memory interleaving, which enables multiple concurrent accesses, the probability of conflicts can be significantly reduced.

[0085] The microcontroller 201 can retrieve data and instructions from external memory device 234 to replace temporary load units 220 in instruction cache 218. If one processor core 202, 204, 206 wants to replace a temporary load unit 220, but another processor core 202, 204, 206 does not, the cache replacement manager 230 determines which load unit 220 to replace based on information from the operating system of processor cores 202, 204, 206 and the tasks being performed in each of processor cores 202, 204, 206, as will be described more fully below. The size of internal memory 216 can be selected to accommodate smaller load units 220 of variable size, while the remaining instructions and data corresponding to portions of the application that are not scheduled to be executed remain in external memory device 234. As a result, if external memory device 234 is unavailable, the size of internal memory 216 will be smaller than would have been required to accommodate all the data and instructions associated with a particular application.

[0086] Processing system 200 can manage a set of cache eviction candidates, enabling the variable-sized load unit 260 to be used for cache management, thereby effectively decoupling the generation of cache eviction candidates from their use for cache eviction. This decoupling allows for a larger time span between the generation and use of cache eviction candidates, which allows for more sophisticated searching for “optimized” candidates. In contrast, conventional L1 / L2 caches 208, 210, 212, which operate on demand, must provide eviction candidates more or less immediately.

[0087] The ability to search for more optimized eviction candidates allows advantageous cache replacement strategies to attempt to retain more "valuable" load units within the OTC instruction cache 218 by better selecting eviction candidates. However, such selection processing can be expensive in terms of the number of operations required, which translates into a time span required for the work, making it desirable to avoid unnecessary operations. For this purpose, the selection rate used to generate cache eviction candidates can be controlled to allow the selection of cache eviction candidates to be adjusted as the current processing needs of system 200 become apparent. In some embodiments, the fill level of the area used to store eviction candidates in cache replacement manager 230 can be used as a criterion for controlling the selection process. A set of control levels (e.g., DRAIN, ERROR, and EMPTY levels) can be defined, and an acceleration factor (e.g., accelerated selection rate x2, x8, x16) can be assigned to each control level. Eviction candidates can then be selected using a base selection rate, and the selection rate used to generate cache eviction candidates can be accelerated whenever one of the control levels is reached. For example, when a three-quarters fill level is specified as the DRAIN level, the selection rate can be doubled to generate twice the number of cached eviction candidates when a potential set of managed eviction candidates is less than three-quarters full. When the area used to store such candidates is filled again, the selection rate can revert to the basic (slower) speed.

[0088] The functions performed by the load entity queue 226 include selecting and rejecting eviction candidates. The cache replacement manager 230 performs arbitration among N managed eviction candidates to identify them, broadcasts the identified eviction candidates to the load entity queue 226, and receives confirmations and / or rejections of the identified eviction candidates. The address mapping device 245 generates requests for eviction candidates when needed and processes the eviction of identified eviction candidates when the load manager 228 loads the requested load unit 260 requiring eviction candidates. The cache replacement manager 230 provides eviction candidates from its managed eviction candidates 236 according to the request from the address mapping device 245. The cache replacement manager 230 also broadcasts the identified eviction candidates to the load entity queue 226 and receives confirmations and / or rejections of the eviction candidates. Rejected eviction candidates will not be used, and the rejection process is repeated after another eviction candidate is selected. Processes executed by execution units in the OTC controller 224, which includes a load entity queue 226, a cache replacement manager 230, an address mapping device 245, and a load manager 228, can be executed concurrently independently of other processes. Furthermore, when multiple execution units are available, any process can be executed concurrently by multiple related execution units, thereby generating multiple eviction candidate processes.

[0089] The process of selecting eviction candidates can be performed by one or more of the N load entity queues 226 that manage a set of load units 260, such as any load entity queue 226 associated with a bus master having the characteristics of processor cores 202, 204, 206. Typically, the processor cores 202, 204, 206 bus masters will be a subset of the bus masters 202, 204, 206, 207 implemented within the microcontroller 201.

[0090] Figures 3-5 This illustrates the management process performed by the corresponding load entity queue 126, cache replacement manager 230, address mapping device 245, and load manager 228 according to the selected embodiment. Figure 2 The flowcharts for processing cache eviction candidates in the processing system 200 are as follows: 310, 340, 320, and 370.

[0091] The candidate selection process 310 can be executed continuously and can include, for example, Figure 3 The processes shown are 302-309. (Reference) Figure 2 and 3 The eviction candidate selection process 310 begins with process 302 to select eviction candidates from a subset of load units 260 managed by a specific load entity queue 226. For example, eviction candidates from the specific load entity queue 226 may be randomly selected by choosing one of the managed subsets of load units 260 in a predetermined order, or by any other selection criteria that can be defined for such a process. Process 304 determines the replacement priority of the selected cache eviction candidates. For example, a predetermined replacement priority may be used as a criterion for selecting cache eviction candidates. If the determined replacement priority for the selected cache eviction candidate is insufficient, process 305 may abort further processing of the specific eviction candidate and return to process 302.

[0092] If the replacement priority is sufficient, process 305 transitions to process 306 to forward the selected cache eviction candidate and any other relevant information to the cache replacement manager 230. The forwarding operation in process 306 may involve an optional handshake process 307, which awaits confirmation 309 from the cache replacement manager 230 that the selected cache eviction candidate has been accepted for further processing. For example, eviction candidates are provided so quickly in multiple load entity queues 226 that eviction candidate management process 420 (… Figure 4If they cannot be processed immediately, a handshake process 307 may be necessary because earlier forwarded eviction candidates are still being processed, and there is insufficient storage space to record the received eviction candidates for later processing. In other embodiments, the handshake process 307 may not be implemented, and alternatively, the selected eviction candidates may be discarded when processing resources are unavailable. In this case, an acknowledgment 309 may be generated immediately without involving the cache replacement manager 230. Once the selected eviction candidate has been acknowledged for further processing (or has been discarded), process 308 transitions to process 302 to repeat the eviction candidate selection processes 302-309.

[0093] Now for reference Figure 2 and 4 , Figure 4 The flowchart illustrates an example of a process performed by a cache replacement manager 230, which includes an eviction candidate management process 420 that maintains managed eviction candidates 236. The candidate management process 420 includes a candidate acceptance process 419, which can be concurrently executed by a replication hardware element providing new eviction candidates to an equal number of N load entity queues 226. In other embodiments, the candidate acceptance process 419 can be repeatedly executed by a single set of hardware elements observing a handshake process 307 of N load entity queues 226. The remaining processing of the eviction candidate management process 420 is typically performed only once within a single cache replacement manager 230; however, multiple cache replacement managers 230 may be needed to manage multiple lists of managed eviction candidates 236. For example, when using fragmented memory, multiple lists of managed eviction candidates 236 may be required, and each memory segment requires one list of managed eviction candidates 236.

[0094] Candidate acceptance processing 419 can be executed continuously, starting with processing 412, receiving eviction candidates that have been forwarded from loading entity queue 226. Process 412 records the eviction candidates, and then an acknowledgment signal can be generated, which is sent to candidate selection processing 310 via handshake processing 307. Process 414 selects new eviction candidates for further processing, and may use some selection criteria, such as replacement priority associated with the eviction candidate. Process 415 can compare the selection criteria with corresponding information associated with other eviction candidates stored in the list of managed eviction candidates 236. For example, process 415 may include determining whether the new eviction candidate has sufficient relevance to be added as a new eviction candidate. For example, relevance may be determined by a minimum priority that may be hardcoded, programmable, or performed depending on other eviction candidates. If the new eviction candidate does not meet the selection criteria or is insufficiently relevant, the new candidate may be discarded, and process 415 transitions to process 412 to receive and record another eviction candidate. Otherwise, process 415 transitions to process 450.

[0095] The remainder of the eviction candidate management process 420 can have multiple triggering events; for example, trigger A can occur when candidate acceptance 419 has accepted a new eviction candidate and will proceed with further processing. When eviction requires processing 570 ( Figure 5 Trigger B may occur when an eviction request is identified and forwarded to the cache replacement manager 230 via handshake process 460. Trigger C may occur when neither trigger A nor B occurs and the default process is selected. Each trigger A, B, and C has associated eviction candidates, and therefore arbitration process 450 may be used to select one of the eviction candidates from triggers A, B, or C for further processing. In some embodiments, the eviction candidate associated with trigger B has the highest priority and is always selected when present. Before the eviction candidate associated with trigger B is forwarded to arbitration process 450, process 451 may be performed to determine the next eviction candidate in the list of managed eviction candidates 236 according to predetermined criteria. Process 451 forwards the determined eviction candidate to arbitration process 450.

[0096] The expulsion candidate associated with trigger A can have the next highest priority and can be selected if there is no expulsion candidate associated with trigger B. New expulsion candidates accepted by expulsion candidate acceptance process 419 are forwarded to arbitration process 450.

[0097] The eviction candidate associated with trigger C may have the lowest priority and may be selected when there are no other eviction candidates from trigger A or B. In some embodiments, trigger C may not be implemented. However, if an eviction candidate is used for trigger C, process 449 may be performed to determine an eviction candidate from managed eviction candidates 236 for forwarding to arbitration process 450.

[0098] Once Arbitration Procedure 450 is executed, subsequent processing is equivalent in many respects for the expulsion candidates associated with triggering A, B, or C. The expulsion candidate selected in Arbitration Procedure 450 is also referred to as the "queried expulsion candidate".

[0099] Following arbitration process 450, process 452 forwards information about the queried eviction candidate to all M load entity queues 226 via M handshake interfaces 331. Process 455 may wait until an acknowledgment signal is sent from all M load entity queues 226, or until a single rejection signal for the queried eviction candidate is received from one or more of the M load entity queues 226 via handshake interfaces 331.

[0100] In process 455, process 456 is executed after all M loading entity queues 226 have provided acknowledgment signals or one or more of the M loading entity queues 226 have provided denial signals. Process 456 determines the query status of the queried eviction candidate, which is either rejected (V) upon receiving at least one denial signal for the queried eviction candidate, or approved (G) upon receiving acknowledgment signals for the queried eviction candidate from all M loading entity queues 226.

[0101] In process 457, when the queried eviction candidate is associated with trigger A and agrees to the query status (denoted as "AG"), process 458 is executed to add the queried eviction candidate to the list of managed eviction candidates 236. If the list of managed eviction candidates 236 is already full, the queried eviction candidate can replace one or more eviction candidates in the list of managed eviction candidates 236. Process 458 may determine that the queried eviction candidate has insufficient replacement priority compared to eviction candidates already filling the list of managed eviction candidates 236. In this case, the queried eviction candidate is not added to the list of managed eviction candidates 236, and process 458 transitions to arbitration process 450 when candidate acceptance process 419 is executed independently of the remainder of eviction candidate management process 420, or transitions to process 412 to select a new eviction candidate when process 419 and the remainder of process 420 are executed sequentially.

[0102] When the queried eviction candidate is associated with trigger A and the query status is rejected (represented as "AV"), the queried eviction candidate is discarded, and when the candidate acceptance process 419 is executed independently of the rest of the eviction candidate management process 420, process 458 is switched to arbitration process 450, or when process 419 and the rest of process 420 are executed in sequence, it is switched to process 412 to select a new eviction candidate.

[0103] When a queried eviction candidate is associated with trigger B and agrees to the query (represented as "BG"), process 445 can be executed to provide the information associated with the queried eviction candidate, along with an acknowledgment signal, to handshake process 460. Process 445 then proceeds to process 450 for the next round of arbitration for the eviction candidate. Alternatively, when a queried eviction candidate is associated with trigger B and denies the query (represented as "BV"), process 448 is executed to remove the queried eviction candidate from the list of managed eviction candidates 236, or to set a flag associated with the queried eviction candidate to prevent further processing and modify the replacement priority of the queried eviction candidate to a level that prevents the selection of the queried eviction candidate. Then, the information associated with the queried expulsion candidate is provided to the handshake process 460 along with a rejection signal, and process 448 is switched to any arbitration process 450 when candidate acceptance process 419 is performed independently of the remainder of expulsion candidate management process 420, or switched to process 412 to select a new expulsion candidate when process 419 and the remainder of process 420 are performed in sequence.

[0104] When a queried eviction candidate is associated with trigger C and agrees to the query status (represented as "CG"), the queried eviction candidate is not processed further, and process 457 transitions to arbitration process 450 for the next round of arbitration against the eviction candidate. When a queried eviction candidate is rejected for the query status (represented as "CV") associated with trigger C, process 457 transitions to process 448 to remove the queried eviction candidate from the list of managed eviction candidates 236, or to set a flag associated with the queried eviction candidate to prevent further processing and modify the replacement priority of the queried eviction candidate to a level that prevents the selection of the queried eviction candidate. Then, when candidate acceptance process 419 is executed independently of the remainder of eviction candidate management process 420, process 448 transitions to arbitration process 450, or when process 419 and the remainder of process 420 are executed sequentially, transitions to process 412 to select a new eviction candidate.

[0105] The remainder of processes 419 and 420 can be executed sequentially or independently of each other. Except when processing a queried eviction candidate with a query status of "BV", when candidate acceptance process 419 is executed independently of the remainder of eviction candidate management process 420, eviction candidate management process 420 continues from processes 457, 458, 445 to any one of arbitration processes 450, or when processes 419 and the remainder of process 420 are executed sequentially, it continues to process 412 to select a new eviction candidate. When a queried eviction candidate has a query status of BV, process 448 transitions to process 451 to select another eviction candidate. Process 451 then transitions to arbitration process 450 to restart the arbitration process.

[0106] Refer again Figure 2 and 3 , Figure 3 A flowchart illustrating an embodiment of a candidate rejection process 340 that can be executed by each of the M load entity queues 226 for both processor core and non-processor core bus masters 202-207. The candidate rejection process 340 can be executed sequentially and independently of the candidate selection process 310.

[0107] Process 332 receives eviction candidates broadcast by cache replacement manager 230 via handshake process 331. Process 334 compares the broadcast eviction candidates with a set of load unit instances identified as needed by load entity queue 226. If load entity queue 226 does not require broadcast eviction candidates, process 334 sends an acknowledgment signal to handshake process 331 without providing a denial signal, and process 332 may receive further broadcast eviction candidates via handshake process 331. If process 334 determines that load entity queue 226 requires broadcast eviction candidates, process 336 provides both a denial signal and an acknowledgment signal to handshake process 331. Handshake process 331 then transmits the acknowledgment signal and the denial signal to cache replacement manager 230.

[0108] Now for reference Figure 2 and 5 , Figure 5The flowchart illustrates an example of a process performed by load manager 228, which includes an eviction requirement process 570 that generates a selection of eviction candidates. When load manager 228 receives a load unit request, it executes eviction requirement process 570. Process 562 receives load unit information 232 corresponding to the requested load unit 260 and begins read access from external memory 234 by load manager 228. Process 564 reads the contents of the requested load unit 260 (or a portion thereof) from external memory 234 until the buffer memory in load manager 234 is full. In process 566, load manager 228 queries address mapping device 245 to obtain free storage space within instruction cache 218. When there is sufficient free storage space in instruction cache 218, process 568 transitions to process 578 to store all or part of a temporary copy 220 of load unit 260 in instruction cache 218. When the address mapping device 245 cannot identify enough space to store all or part of the temporary load unit 220, which is a copy of the requested load unit 260, in the instruction cache 218, the process 572 creates an eviction request and forwards the eviction request to the handshake process 460.

[0109] Process 573 waits until an acknowledgment signal is received via handshake process 460. When the acknowledgment signal is received in process 573, process 576 uses the information received along with the acknowledgment signal regarding the selected eviction candidate and uses address mapping device 245 to evict the corresponding temporary load unit 220 in instruction cache 218. If process 577 determines that there is insufficient space to store the temporary load unit 220 as a copy of the requested load unit 260, process 577 transfers control to process 572 to create another eviction requirement. Processes 572 through 577 may be repeated until the available storage area in instruction cache 218 is sufficient to store all or part of the temporary load unit 220 as a copy of the requested load unit 260. When process 577 determines that there is sufficient space to store all or part of the temporary copy 220 of the requested load unit 260 in instruction cache 218, process 577 transitions to process 578 to store all or part of the temporary load unit 220 in instruction cache 218. Process 579 determines whether temporary load unit 220 has been fully loaded; if so, process 570 completes. If temporary load unit 220 has not been fully loaded, process 579 proceeds to process 564 to read another portion of the requested load unit. Processes 564 to 579 are repeated until a complete copy of the requested load unit 260 is copied to the corresponding temporary load unit 218 in the instruction cache 218.

[0110] It should now be understood that, in some embodiments, a processing system has been provided that may include a microcontroller device and an external memory device external to the microcontroller device. The external memory device may be coupled to the microcontroller device. The microcontroller device may include a bus master (202-206) configured to execute application code, and a random access memory (RAM) device (216) internal to the microcontroller device and coupled to the bus master via interconnects. The RAM device may include a system memory portion (222) and an instruction portion (218). The instruction portion may be configured to store copies of a subset of load units from the external memory device for use by the application code. Load units may include executable instructions and / or data and are associated with a corresponding one in the application code. A cache controller device (224) may be coupled to the random access memory and the external memory device and may include a load entity queue. Each of the load entity queues is associated with one of the bus masters. The cache controller can be configured to: manage a set of eviction candidates; periodically select eviction candidates from copies of load units in the instruction section; discard eviction candidates if at least one in the load entity queue rejects an eviction candidate; and replace the eviction candidates in the instruction section with copies of the requested load units.

[0111] On the other hand, each of the loading entity queues can be configured to request loading of a loading unit (260) and periodically select eviction candidates to be included in a set of managed eviction candidates from copies of loading units in the instruction portion associated with the loading entity queue.

[0112] On the other hand, the cache controller may additionally include an address mapping device (245) for managing the instruction portion (218) of the internal memory (216), including tracking the memory area occupied by a subset of copies of the load unit (220) and the available memory area within the instruction portion not occupied by a subset of copies of the load unit.

[0113] On the other hand, the cache controller may additionally include a load manager device configured to process requests to load load units from external memory devices and to query in the address mapping device for available storage locations within the instruction portion (218) that are large enough to store copies of at least a portion of the requested load unit.

[0114] On the other hand, the processing system may additionally include a cache replacement manager (230) coupled to the load entity queue 226 and the address mapping device. When there is insufficient storage space to store a complete copy of the requested load unit, the cache replacement manager can select one of a set of managed eviction candidates based on a request from the address mapping device (245) and verify the selected eviction candidate. The address mapping device (245) responds to the query from the load manager (228) by providing an available storage location when sufficient storage space is available, and repeatedly requesting additional eviction candidates from the cache replacement manager (230) and evictioning additional eviction candidates from the instruction section until there is sufficient storage space in the instruction section available for a complete copy of the requested load unit.

[0115] On the other hand, the cache controller device can be further configured to: broadcast eviction candidates to the load entity queues; and verify the eviction candidates when an acknowledgment signal is received and there is no rejection response from all load entity queues.

[0116] On the other hand, when the corresponding loading entity queue does not currently require a loading unit corresponding to the eviction candidate, the corresponding loading entity queue may agree to use the broadcast eviction candidate.

[0117] On the other hand, each load entity queue can be associated with a specific bus master, and each load entity queue only manages the load units associated with the application code executed by the corresponding bus master.

[0118] On the other hand, when a loading unit satisfies at least one of the following conditions: a) the loading unit is currently being used by the bus master associated with the loading entity queue, b) the loading unit has recently been used by the bus master associated with the loading entity queue, and c) the loading entity queue knows that the loading unit will be used by the bus master associated with the loading entity queue in the foreseeable future, the corresponding loading entity queue may identify a copy of the loading unit as currently needed.

[0119] On the other hand, each load cell can be specified by an address range corresponding to an address range in external memory, and at least two of the load cells have different lengths.

[0120] In other embodiments, a method for managing load units of executable instructions between internal memory in a microcontroller having multiple bus masters and a non-volatile memory device external to the microcontroller, the method may include loading copies of load units from external memory devices into internal memory for use by a corresponding bus master. Each load unit may be associated with a corresponding load entity queue, and each load entity queue is associated with a corresponding one of a plurality of bus masters. Each load entity queue may select eviction candidates from the associated copies of load units currently loaded in internal memory. Information identifying eviction candidates for each load entity queue may be broadcast to all load entity queues. If no load entity queue rejects the use of an eviction candidate, the eviction candidate may be added to a set of managed eviction candidates.

[0121] In another aspect, the method may further include: periodically selecting eviction candidates from copies of load units in internal memory associated with each load entity queue; discarding eviction candidates if at least one in the load entity queue rejects an eviction candidate; and replacing the eviction candidate in internal memory with a copy of the requested load unit.

[0122] On the other hand, if a copy of a loading unit is being used in the loading entity queue, the loading entity queue rejects the candidate for eviction.

[0123] In another aspect, the method may additionally include approving an eviction candidate when all load entity queues determine at least one of the following: a) the eviction candidate does not correspond to a copy of the currently used load unit, and b) a copy of the load unit corresponding to the eviction candidate has not been used recently.

[0124] On the other hand, the method may additionally include managing the copies of the loading unit in the internal memory (216) by tracking the storage area occupied by each copy of the loading unit (220) and the available storage area in the internal memory not occupied by the copies of the loading unit, wherein at least two of the copies of the loading unit have different lengths.

[0125] On the other hand, the method may additionally include querying an available storage location within internal memory (116) that is large enough to store a copy of the requested load unit or a portion thereof.

[0126] On the other hand, the method further includes responding to the query by providing an available storage location when sufficient storage space is available, and repeatedly requesting additional eviction candidates until there is sufficient storage space in the instruction portion available for loading a copy of the unit.

[0127] In another aspect, the method may additionally include verifying the eviction candidate when an acknowledgment signal is received without a rejection response from all loading entity queues.

[0128] In another aspect, the method may additionally include agreeing to use a broadcast eviction candidate when the corresponding loading entity queue does not currently require a copy of the loading unit associated with the eviction candidate.

[0129] On the other hand, each load entity queue can be associated with a specific bus master, and each load entity queue only manages the load units associated with the application code executed by the corresponding bus master.

[0130] While the exemplary embodiments described herein relate to methods and systems applicable to systems and methods for managing cache replacement, the invention is not necessarily limited to the example embodiments shown herein, and various embodiments of the circuit systems and methods disclosed herein can be implemented with other means and circuit components. Therefore, the specific embodiments disclosed above are merely illustrative and should not be considered as limiting the invention, as the invention can be modified and implemented in different but equivalent ways, which will be apparent to those skilled in the art who benefit from the teachings herein. Accordingly, the foregoing description is not intended to limit the invention to a particular form, but rather is intended to cover such alternatives, modifications, and equivalents that may be included within the spirit and scope of the invention as defined by the appended claims, such that those skilled in the art should understand that they can be changed, substituted, and varied in their broadest form without departing from the spirit and scope of the invention.

[0131] Various illustrative embodiments of the invention have been described in detail with reference to the accompanying drawings. While various details are set forth in the foregoing description, it should be understood that the invention can be practiced without these specific details, and many specific implementation decisions can be made with respect to the invention described herein to achieve specific goals of circuit designers, such as compliance with process technology or associated design constraints that vary with different implementations. While such research and development work may be complex and time-consuming, it is merely a routine task of daily work for those skilled in the art who will benefit from this disclosure. For example, selected aspects are shown in block diagram form rather than in detail in order to avoid limiting or obscuring the invention. Furthermore, some portions of the detailed description provided herein can be implemented as software or as operations on data within computer memory, implemented by hardware circuitry or firmware, or a combination of software, hardware, and firmware. Such descriptions and representations are used by those skilled in the art to substantially describe and convey the work of others skilled in the art. For example, MCU 201 ( Figure 2Microcontrollers (MCUs), such as systems-on-a-chip (SoCs), are examples of small computer processing systems formed by integrated circuits. Each processing system includes one or more central processing units (CPUs), memory for storing executable software instructions and / or data, programmable peripherals such as timers, etc. Integrated circuits are used to execute software and / or firmware instructions, and / or, individually, hardware circuitry to perform specific functions and / or store information. This disclosure is described with reference to MCU 201 and / or methods and processes performed on MCU 201. It should be understood that this disclosure can be used in many types of computer processing systems and should not be limited to use in MCUs. The term "apparatus" as used herein refers to a circuit system that stores information such as instructions and / or data and / or executes instructions in software or firmware, the hardware circuitry itself, and / or a combination of circuit systems used to store instructions and / or data and / or perform functions using software, firmware, and / or hardware.

[0132] The foregoing description of specific embodiments has described benefits, other advantages, and solutions to problems. However, those benefits, advantages, solutions to problems, and any elements that cause any benefit, advantage, or solution to a problem to occur or become more significant should not be construed as key, required, or essential features or elements of any or all claims. As used herein, the terms “comprises,” “comprising,” or any other variations thereof are intended to cover non-exclusive inclusions, such that a process, method, apparatus, article, or device that comprises a list of elements includes not only those elements but may also include other elements not expressly listed or not inherent to such process, method, apparatus, article, or device.

[0133] While this disclosure has been described herein with reference to specific embodiments, various modifications and changes may be made without departing from the scope of this disclosure as set forth in the appended claims. Therefore, this specification and drawings should be viewed in an illustrative rather than restrictive sense, and all such modifications are contemplated to be included within the scope of this disclosure. It is not intended that any benefit, advantage, or solution to a problem described herein with reference to specific embodiments be construed as a key, necessary, or essential feature or element of any or all claims.

Claims

1. A processing system, characterized in that, include: Microcontroller devices; An external memory device located outside the microcontroller device, the external memory device being coupled to the microcontroller device; The microcontroller device includes: The bus master is configured to execute application code; A random access memory (RAM) device is located within the microcontroller device and coupled to the bus master via interconnects. The RAM device includes a system memory portion and an instruction portion. The instruction portion is configured to store copies of a subset of load units from the external memory device for use by the application code. The load units include executable instructions and / or data and are associated with a corresponding one in the application code. A cache controller device coupled to the random access memory and the external memory device and including a load entity queue, each of the load entity queue being associated with one of the bus masters, the cache controller device being configured to: Managing a set of eviction candidates includes: selecting further eviction candidates to include in the set of eviction candidates, and removing a first eviction candidate selected from the set of eviction candidates to replace it with a copy of the requested loaded unit; Based on a controllable selection rate, a second eviction candidate is selected from the copies of the loading units in the instruction section to be included in the set of eviction candidates; If at least one of the loaded entity queues rejects the first or second eviction candidate, then the first or second eviction candidate is discarded, wherein the rejection is configured to occur at one or more of the following: before the second eviction candidate is included in the set of eviction candidates, before the first eviction candidate is replaced with a copy of the requested loaded unit; and In response to selecting the first eviction candidate from the set of eviction candidates, the first eviction candidate selected from the set of eviction candidates in the instruction portion is replaced with a copy of the requested load unit stored in the external memory device.

2. The processing system according to claim 1, characterized in that, Each of the loading entity queues is configured to request the loading of a loading unit, and a second eviction candidate to be included in the set of managed eviction candidates is selected from the copies of the loading units in the instruction portion associated with the loading entity queue based on the controllable selection rate.

3. The processing system according to claim 1, characterized in that, The cache controller further includes: An address mapping device capable of operating to manage the instruction portion of the RAM device, including tracking the storage area occupied by copies of a subset of the loading units and the available storage area within the instruction portion not occupied by copies of a subset of the loading units.

4. The processing system according to claim 1, characterized in that, The cache controller device is further configured to: Broadcast the first eviction candidate or the second eviction candidate to the loading entity queue; When an acknowledgment signal is received but no rejection response is received from any of the loaded entity queues, verify either the first eviction candidate or the second eviction candidate.

5. The processing system according to claim 1, characterized in that, Each load entity queue is associated with a specific bus master, and each load entity queue manages only the load units associated with the application code executed by the corresponding bus master.

6. A method for managing a loading unit for executable instructions between internal memory in a microcontroller having multiple bus masters and a non-volatile memory device external to the microcontroller, characterized in that, The method includes: A copy of the loading unit is loaded from the non-volatile memory device into the internal memory for use by the corresponding bus master. Each loading unit is associated with a corresponding loading entity queue and each loading entity queue is associated with a corresponding one of the plurality of bus masters. For each loaded entity queue, based on a controllable selection rate, eviction candidates are selected from the associated copies of the loaded units currently loaded in the internal memory; Broadcast the information identifying the eviction candidates for each loaded entity queue to all loaded entity queues; and If no loading entity queue rejects the use of the eviction candidate, then the eviction candidate is added to a group of managed eviction candidates.

7. The method according to claim 6, characterized in that, In addition, including: Based on the controllable selection rate, eviction candidates are selected from the copies of the loading units associated with each loading entity queue in the internal memory; If at least one of the loaded entity queues rejects the eviction candidate, then the eviction candidate is discarded. as well as Replace the eviction candidate in the internal memory with a copy of the requested loaded unit.

8. The method according to claim 6, characterized in that, If a copy of the loading unit is being used in the loading entity queue, the loading entity queue rejects the eviction candidate.

9. The method according to claim 6, characterized in that, In addition, including: The copies of the loading unit in the internal memory are managed by tracking the storage area occupied by each copy of the loading unit and the available storage area in the internal memory not occupied by the copies of the loading unit, wherein at least two of the copies of the loading unit have different lengths.

10. The method according to claim 6, characterized in that, Each load entity queue is associated with a specific bus master, and each load entity queue manages only the load units associated with the application code executed by the corresponding bus master.

Images