CONFIGURING A PREFETCHER ASSOCIATED WITH A PROCESSOR CORE

Disclosed are systems and methods for configuring a prefetcher. A process may reconfigure a prefetcher associated with a processor core responsive to a context switch. The context switch may comprise the processor core changing from executing a first process to a second process. In some implementations, reconfiguring the prefetcher may include updating a register controlling an operation of the prefetcher from a first set of parameters associated with the first process to a second set of parameters associated with the second process. In some implementations, the second set of parameters may be based on input from a process executed in a user mode.

FIELD OF TECHNOLOGY

This disclosure relates generally to processors, and more specifically, to configuring a prefetcher associated with a processor core.

BACKGROUND

A prefetcher is used to retrieve data from memory, prior to the data being requested by a central processing unit (CPU) or processor core, in order to reduce the waiting time for memory which may then improve the throughput of the processor core. The prefetcher predictively reads memory locations before they are requested based on how the prefetcher is designed, which may include parameters that may be set at the initialization of the prefetcher. For example, if a process is reading every 64thbyte of a large array and the accesses are missing in a level 1 (L1) cache associated with the processor core, the prefetcher may detect these misses. The prefetcher may then allocate the appropriate memory addresses to the level 2 (L2) cache, so that subsequent accesses to the array will hit in the L2 cache. This may reduce overall access time to the array and improve the performance of the process (e.g., the application).

DETAILED DESCRIPTION

A central processing unit (CPU) or processor core may experience latency when fetching data from memory (e.g., when fetching instructions or data from cache or main memory). For example, fetching data from memory may involve the processor core initiating a request to a memory controller and waiting for the memory controller to retrieve the data from memory. Additionally, the processor core might compete with other processor cores and/or direct memory access (DMA) controllers for accessing the memory. To reduce latency, the processor core may use a prefetcher to fetch data from memory in advance of when the data may be used by a process executing in the processor core (e.g., a “prefetch,” or simply a “fetch”). A kernel of an operating system hosting the process may configure the prefetcher, such as by applying a set of parameters to one or more registers controlling operation of the prefetcher. Configuring the prefetcher may permit controlling how the prefetcher fetches data from memory (e.g., controlling one or more characteristics associated with fetching data from memory). For example, the kernel may configure the prefetcher to control a number of streams that the prefetcher will track, a distance associated with a fetch (e.g., a separation between a prefetch tail pointer and a demand pointer), a window associated with a fetch (e.g., a number of cache lines to detect an address match), and/or a size associated with a fetch.

Different processes executing in the processor core could possibly have different memory access patterns. For example, a web browser may have a memory access pattern that is different than a mathematically intensive application which may be executing many matrix multiplication operations. It may be desirable to change the configuration of a prefetcher for a given process, based on its memory access pattern, in order to optimize fetching data from memory for the process (e.g., improve the accuracy of the fetch).

Techniques described herein permit changing a set of parameters being used by a prefetcher on a per process basis at run time. The set of parameters may be changed responsive to a context switch where a processor core changes from executing a first process to a second process. For example, a set of parameters (colloquially knobs) may be changed for a given process based on a memory access pattern associated with the process. The set of parameters may be applied to one or more registers controlling operation of a prefetcher. Changing the set of parameters may permit controlling one or more characteristics associated with fetching data from memory (e.g., how the prefetcher fetches the data from memory). For example, changing the set of parameters may permit controlling one or more characteristics, such as a number of streams that the prefetcher will track, a distance associated with a fetch, a window associated with a fetch, allowing a linear to exponentially increasing distance, and/or a size associated with a fetch. As a result, changing the set of parameters may control a level of aggressiveness when fetching data (e.g., fetching more data in advance for a process versus a risk of fetching data that might go unused or under used by the process). The set of parameters may be applied to one or more registers controlling operation of the prefetcher which may be protected (e.g., accessible in a higher privileged mode than a mode associated with a user mode). In some implementations, the set of parameters may be controlled by a kernel of an operating system (e.g., Linux®) that is executing in the higher privileged mode. A process executing in a lower privileged mode (e.g., a user mode) may provide input for changing the set of parameters for a given process. The kernel may receive the input and configure (or reconfigure) the set of parameters for the prefetcher based on the input. In some implementations, the process that provides the input may be the same process for which the prefetcher will fetch data. In some implementations, the process that provides the input may be a system management process that is separate from the process for which the prefetcher will fetch data. Thus, the configuration of a prefetcher may be changed dynamically, on a per process basis at run time, so as to optimize the fetching of data from memory for a given process. In some implementations, the configuration of a prefetcher may be changed for a process based on a memory access pattern associated with the process.

FIG.1is a block diagram of an example of a system100that includes a processor core associated with a prefetcher. The system100may include a processor core110, a prefetcher120associated with the processor core110, and a memory system (e.g., “memory”), such as a cache system130and/or a main memory system140. The processor core110and the prefetcher120may be associated with one another in a processing node150(e.g., a tile). In some implementations, the processing node150may be implemented with other processing nodes in a cluster. The processing node150may be implemented in an integrated circuit (IC), such as an application-specific integrated circuit (ASIC) or system on a chip (SoC). The processor core110may include a level 1 (L1) cache which may be divided into an instruction level 1 (IL1) cache and/or a data level 1 (DL1) cache. The cache system130may implement a cache controller and a cache memory (e.g., static random access memory (SRAM)) for the processing node150. For example, the cache system130may implement a private level 2 (L2) cache associated with the processing node150, and/or a shared level 3 (L3) cache associated with multiple processing nodes, including the processing node150. The main memory system140may implement a memory controller and a main memory (e.g., dynamic random access memory (DRAM)) associated with one or more processing nodes, including the processing node150.

The processor core110may include an execution unit for executing instructions and processing data and may be implemented with other processor cores. For example, the processor core110could be a RISC-V processor. The processor core110may execute one process or task at a time, such as executing one of process160A (e.g., a kernel of an operating system such as Linux), process160B (e.g., a process associated with a user application being hosted by the operating system, such as a web browser), and process160C (e.g., another process associated with a user application being hosted by the operating system, such as a mathematically intensive program). Such processes may be uniquely identified in the system by a process identifier (PID). Additionally, the processor core110may switch between executing different processes based on an event (e.g., context switching, or multitasking), such as switching from executing process160A to executing process160B or switching from executing process160B to executing process160C. For example, when executing a first process (e.g., process160A), a second process (e.g., process160B) may held in suspension (or might not have started). Then, an event (or trigger) may cause a context switch to occur, such as a timeout associated with executing the first process or an interrupt associated with the second process. In such an event, context data associated with the first process (e.g., contents of the general purpose registers of the processor core110, and/or a memory map or set of addresses available to the first process) may be saved, and context data associated with the second process (e.g., contents of the general purpose registers of the processor core110, and/or a memory map or set of addresses available to the second process) may be restored (or generated if the second process has not yet started). Then, the processor core110may resume (or begin) executing the second process while holding the first process in suspension.

To reduce latency in the system100, the prefetcher120may fetch data from the memory system for one or more processes executing in the processor core110in advance of when the data may be used by the one or more processes. For example, the prefetcher120may fetch data from the memory system for the process160B (e.g., the web browser) when the processor core110is executing process160B. The prefetcher120may fetch the data for the process160B in advance of when the data may be used by the process160B. The prefetcher120may also fetch data from the memory system for the process160C (e.g., the mathematically intensive program) when the processor core110is the executing process160C. The prefetcher120may fetch such data for the process160C in advance of when the data may be used by the process160C.

The prefetcher120may be configured to use a set of parameters (e.g., a first set of parameters) that controls one or more characteristics associated with fetching data from memory. For example, the set of parameters may configure the prefetcher to control a number of streams that the prefetcher will track, a distance associated with a fetch, a window associated with a fetch, allowing a linear to exponentially increasing distance, and/or a size associated with a fetch. For example, the prefetcher120may be configured with the set of parameters for when the processor core110executes process160B. In some implementations, the set of parameters may be a default set of parameters. The set of parameters may be controlled by a kernel of an operating system hosting the one or more processes executing in the processor core110, such as the process160A (e.g., the kernel).

The set of parameters may be changed on a per process basis at run time (e.g., during execution of a process in the processor core110). For example, the prefetcher120may be configured again (or reconfigured) with another set of parameters (e.g., a second set of parameters) for use with a process. For example, the prefetcher120may be reconfigured with the second set of parameters for when the processor core110executes process160B. In some implementations, the second set of parameters may be optimized for a memory access pattern that is associated with the process160B (e.g., the web browser). Changing from the first set of parameters to the second set of parameters may permit changing the one or more characteristics associated with fetching data from memory. For example, changing from the first set of parameters to the second set of parameters may permit changing the number of streams that the prefetcher will track, the distance associated with the fetch, the window associated with the fetch, allowing a linear to exponentially increasing distance, and/or the size associated with the fetch. This may permit optimizing the one or more characteristics associated with fetching data from memory based on the memory access pattern associated with process (e.g., process160B).

Further, the prefetcher120may be configured again (or reconfigured) with a third set of parameters for when the processor core110executes process160C. The third set of parameters may be optimized for a memory access pattern associated with the process160C (e.g., the mathematically intensive program). Changing from the second set of parameters to the third set of parameters for process160C may change again the one or more characteristics associated with fetching data from memory. This may permit optimizing the one or more characteristics associated with fetching data from memory based on the memory access pattern associated with the process160C. The prefetcher120may be configured (and reconfigured) many times, on a per process basis at run time, so as to optimize the fetching of data from memory for a given process. Changing the set of parameters may permit optimizing the one or more characteristics associated with fetching data from memory based on the memory access pattern associated with the process.

In some implementations, when a processor core switches from executing a first process to executing a second process (e.g., context switching), the prefetcher120may also be reconfigured at that time from using a first set of parameters for the first process to using a second set of parameters for the second process. In other words, switching the set of parameters used to configure the prefetcher120may be part of a context switch between a first process and a second process. For example, when the processor core110switches from executing process160B to executing process160C, the prefetcher120may also be reconfigured at that time, such as switching from using the second set of parameters for process160B to using the third set of parameters for process160C.

In some implementations, when a new process starts, the prefetcher120may be configured with a default set of parameters for the new process. For example, process160B (e.g., the web browser) may start in the processor core110. The process160A (e.g., the kernel) may configure the prefetcher120with a default set of parameters for when the processor core110executes the process160B. Then, the process160A may reconfigure the prefetcher120with a second set of parameters for when the processor core110executes the process160B. Also, the process160C (e.g., the mathematically intensive program) may start in the processor core110. The process160A may reconfigure the prefetcher120with the default set of parameters for when the processor core110executes the process160C. Then, the process160C may reconfigure the prefetcher120with a third set of parameters for when the processor core110executes the process160B.

In some implementations, when a first process initiates or starts a second process (e.g., a new process), the prefetcher120may be configured to use a same set of parameters for the second process as was used for the first process. In other words, if a parent process creates a child process (e.g., forks), the child process may inherit the same set of parameters as the parent process. For example, if process160B initiates or starts a new process, the prefetcher120may be configured with the second set of parameters (e.g., which is the same set of parameters as was used for the process160B) for when the processor core110executes the new process.

In some implementations, when a process moves from a first processor core to a second processor core (e.g., a task migration), a prefetcher associated with the second processor core may be configured to use a same set of parameters when executing the process as a prefetcher associated with the first processor core. In other words, if a process migrates from one processor core to another, the set of parameters may follow the process from the one processor core to the other. For example, if the process160B moves from the processor core110to another processor core, a prefetcher associated with the other processor core may be configured to use the same set of parameters when executing the process160B as the prefetcher120associated with the first processor core110used when executing the process160B.

In some implementations, a process that the prefetcher120will fetch data for may provide input for changing the set of parameters. For example, the process160B may provide input to the process160A for changing the set of parameters, such as by making a system call and/or writing to a data structure in a virtual file system (e.g., a proc filesystem (procfs) in Linux). The virtual file system may provide a way for user space programs (e.g., the process160B) to communicate with the kernel (e.g., process160A). The process160A may configure (or reconfigure) the prefetcher120with the set of parameters, based on the input from the process (e.g., process160B), for when the processor core110executes the process (e.g., the process160B). In some implementations, one process (e.g., a system management process) may provide input for changing the set of parameters for another process, such as by writing to a data structure in a virtual file system (e.g., procfs). For example, process160C may provide input to process160A for changing the set of parameters for when the processor core110executes process160B. Then, process160A may configure (or reconfigure) the prefetcher120with a set of parameters, based on the input from process160C, for when the processor core110executes process160B.

In some implementations, the prefetcher120may track the success of fetching data from memory for a given process (e.g., a usefulness of the fetches, such as tracking a number of fetches in which the data is unused or under used). The prefetcher120may then change the set of parameters to improve the success of the fetches, analogous to machine learning.

In some implementations, the prefetcher120may be disabled or turned off so that the prefetcher120does not fetch data from memory in advance of a process. For example, the prefetcher120may be disabled or turned off by the kernel (e.g., process160A). The prefetcher120may be disabled or turned off globally (e.g., for all processes executing in the processor core110) or individually (e.g., for one or more processes executing in the processor core110). In some implementations, the prefetcher120may be disabled or turned off to reduce power consumption (e.g., part of a power savings mode). In some implementations, the prefetcher120may be disabled or turned off based on exceeding a number of unsuccessful fetches (e.g., exceeding a number of fetches in which the data is unused or under used).

FIG.2is a block diagram of another example of a system200that includes a processor core associated with a prefetcher. The system200may be like the system100shown inFIG.1. In the system200, a process260B may be executing in a processor core210associated with a prefetcher220. The process260B may execute to initiate or start a process260D (e.g., the process260B may fork). The prefetcher220may be configured to use a same set of parameters for the process260D (when the processor core210executes the process260D) as for the process260B (when the processor core210executes the process260B). In other words, the process260D may inherit the same set of parameters for prefetching as the process260B.

FIG.3is a block diagram of another example of a system300that includes a processor core associated with a prefetcher. The system300may be like the system100shown inFIG.1or the system200shown inFIG.2. The system300may include multiple processor cores, such as processor cores310A and310B. In some implementations, the multiple processor cores may be associated with one another in a cluster. In the system300, a process360C may be executing in a processor core310A associated with a prefetcher320A. The prefetcher320A may be configured with a set of parameters when executing the process360C. Then, the process360C may move from executing in the processor core310A to executing in the processor core310B (e.g., task migration). A prefetcher320B, associated with the processor core310B, may be configured with the same set of parameters when executing the process360C. In other words, when the process360C migrates from the processor core310A to the processor core310B, the same set of parameters used to configure the prefetcher320A for when the process360C executes in the processor core310A may be used to configure the prefetcher320B for when with the process360C executes in the processor core310B.

FIG.4is a block diagram of an example of a system400that configures a prefetcher associated with a processor core. The system may include a user process402(e.g., a process that executes in a user mode), a data structure404, a control process406(e.g., the kernel of an operating system), and a prefetcher420. The process402may be like the process160B or the process160C shown inFIG.1, the process260B or the process260C or the process260D shown inFIG.2, or the process360B or the process360C shown inFIG.3. The control process406may be like the process160A shown inFIG.1, the process260A shown inFIG.2, or the process360A shown inFIG.3. The prefetcher420may be like the prefetcher120shown inFIG.1, the prefetcher220shown inFIG.2, or the prefetcher320shown inFIG.3.

The prefetcher420may include registers422that may be programmed with a set of parameters for controlling operation of the prefetcher420. Configuring the prefetcher420with the set of parameters may control one or more characteristics associated with fetching data from memory for a process, such as a number of streams that the prefetcher will track, a distance associated with a fetch, a window associated with a fetch, allowing a linear to exponentially increasing distance, and/or a size associated with a fetch. In some implementations, the registers422may be protected (e.g., accessible in a higher privileged mode than a mode associated with a user mode). The control process406(e.g., the kernel) may execute in the higher privileged mode to program the registers422with the set of parameters to configure the prefetcher420. Accordingly, the control process406may configure and reconfigure (e.g., change) the set of parameters used by the prefetcher420on a per process basis at run time. For example, the control process406may program the registers422with a first set of parameters for when a first process will be executing and may program the registers422with a second set of parameters for when a second process will be executing. For example, the control process406may program the registers422for a given process when context switching. In some implementations, the control process406may initially program the registers422with a default set of parameters.

In some implementations, the control process406may program the registers422based on input from another process executing in a lower privileged mode associated with a user mode, such as the process402. In some implementations, the process402may be a same process for which the prefetcher420will fetch data. In some implementations, the process402may be a system management process that is separate from a process for which the prefetcher420will fetch data. As the registers422may be protected, the input may be provided to the control process406, such as via a system call and/or writing to the data structure404. The process402may provide the input to the control process406by writing the input to the data structure404(e.g., the data structure404may be writeable by a process when the process is executing in the lower privileged mode). For example, the data structure may be part of a virtual file system (e.g., procfs in Linux). The virtual file system may provide a way for user space programs (e.g., the process402) to communicate the input to the kernel (e.g., the control process406). The process402may write a set of parameters (e.g., “set of parameters1”) to the data structure404, such as by writing 32-bits or 64-bits to the data structure404(analogous to programming a register). The control process406may receive the set of parameters from the data structure404as input and may apply the set of parameters (e.g., apply the input) to program the registers422.

In some implementations, the process402may provide input for multiple processes. For example, the process402may write to the data structure404to provide input including a first set of parameters for use with a first process (e.g., “set of parameters1”), a second set of parameters for use with a second process (e.g., “set of parameters2”), and so forth. The control process406may receive the input and apply the first set of parameters to program the registers422for when the first process will be executing, apply the second set of parameters to program the registers422for when the second process will be executing, and so forth. Thus, the configuration of the prefetcher420may be changed dynamically, on a per process basis at run time, so as to optimize the fetching of data from memory for a given process.

In some implementations, the data structure404may be a same data structure that is used to store context data430associated with context switching between processes executing in the processor core (e.g., defined as a “task_struct” structure in Linux). For example, for a given process, the data structure404may store the contents of general purpose registers of the processor core, a memory map or set of addresses available to the process, and/or the set of parameters for configuring the prefetcher420for use with the process. In some implementations, the set of parameters may be stored in metadata in the data structure404. For example, when context switching from a first process to a second process, the control process406may save a first set of context data associated the first process to the data structure404and restore a second set of context data associated with the second process from the data structure404. Further, when restoring the second set of context data, the control process406may access metadata in the data structure404to restore the second set of parameters to program the registers422for use with the second process.

In some implementations, an interlock may be implemented to prevent an invalid set of parameters from being programmed to the registers422. The interlock may be used to constrain the set of parameters to valid settings. This may prevent the prefetcher420from being configured incorrectly. For example, the interlock may be executed in connection with the process402and/or the control process406. In some implementations, the registers422may be located so as to enable updating the register with the set of parameters after using the prefetcher420during run time (e.g., as opposed to updating the register with the set of parameters during an initial start-up condition). For example, the registers422may be located so as to enable updating the register with a second set of parameters after using the prefetcher420during run time with a first set of parameters.

FIG.5is a flow chart of an example of a process500for a configuring a prefetcher associated with a processor core on a per process basis at run time. The process500may include executing502a first process in a processor core that is associated with a prefetcher that uses a first set of parameters; determining504a second set of parameters for the prefetcher, such as in response to a context switch; reconfiguring506the prefetcher to use the second set of parameters; and executing508a second process in the processor core with the prefetcher using the second set of parameters. For example, the process500may be executed in the system100shown inFIG.1, the system200shown inFIG.2, the system300shown inFIG.3, and/or the system400shown inFIG.4.

The process500may include executing502a first process in a processor core that is associated with a prefetcher that uses first set of parameters. The prefetcher may fetch data from memory, such as a cache or main memory. The prefetcher may be configured to use the first set of parameters to control one or more characteristics associated with fetching data from memory, such as a number of streams that the prefetcher will track, a distance associated with a fetch, a window associated with a fetch, allowing a linear to exponentially increasing distance, and/or a size associated with a fetch. The first set of parameters may be a default set of parameters. The first set of parameters may be applied to one or more registers controlling operation of the prefetcher which may be protected (e.g., accessible in a higher privileged mode than a mode associated with a user mode). The process may be executing in a lower privileged mode that is associated with a user mode.

The process500may also include determining504a second set of parameters for the prefetcher. For example, the second set of parameters may be determined responsive to a context switch from executing the first process to executing the second process. For example, the second set of parameters may be determined by the first process, the second process, a system management process (e.g., which executes in a lower privileged mode and which is separate from the first process and the second process); a control process (e.g., the kernel of an operating system, which executes in a higher privileged and which is operable to configure the prefetcher with the second set of parameters); and/or logic associated with the prefetcher. The second set of parameters may be determined so as to optimize the fetching of data from memory for the second process. In some implementations, the second set of parameters may be determined based on a memory access pattern associated with the second process. In some implementations, the second set of parameters may be determined based on a history of the second process, such as whether the second process forked from another process (e.g., the first process) or whether the second process migrated from another processor core.

The process500may also include reconfiguring506the prefetcher to use the second set of parameters to control the one or more characteristics associated with fetching data from memory. For example, the prefetcher may be reconfigured responsive to a context switch from executing the first process to executing the second process. The second set of parameters may change the one or more characteristics associated with the fetching. The second set of parameters may be applied to one or more registers controlling operation of the prefetcher, such as by the control process (e.g., kernel) executing in the higher privileged mode.

The process500may also include executing508the second process in the processor core with the prefetcher using the second set of parameters. The second set of parameters may optimize the fetching of data from memory for the second process.

FIG.6is a flow chart of an example of a process600for a configuring a prefetcher associated with a processor core based on user input. The process600may include executing602a process in a processor core in a lower privileged mode that is associated with a user mode; writing604a set of parameters to a data structure that is writeable in the lower privileged mode and/or making a system call providing the set of parameters; executing606a control process (e.g., the kernel of an operating system) in a higher privileged mode than a mode to receive the set of parameters from the data structure and/or the system call; and configuring608a prefetcher associated with the processor core to use the set of parameters for a process. For example, the process600may be executed in the system100shown inFIG.1, the system200shown inFIG.2, the system300shown inFIG.3, and/or the system400shown inFIG.4.

The process600may include executing602a process in a processor core in a lower privileged mode that is associated with a user mode. In some implementations, the process may be a same process for which a prefetcher associated with the process core will fetch data. In some implementations, the process may a system management process that is separate from the process for which the prefetcher will fetch data. The process may be associated with a user program.

The process600may also include writing604a set of parameters to a data structure that is writeable in the lower privileged mode and/or making a system call providing the set of parameters. The process executing in the lower privileged mode may write the set of parameters to the data structure and/or make the system call. The process may write the set of parameters and/or make the system call to provide input to a control process executing in a higher privileged mode. In some implementations, the process may provide the input by writing to a data structure in a virtual file system (e.g., procfs). In some implementations, the process may provide the input as metadata in a data structure that is used to store context data associated with context switching between processes executing in the processor core (e.g., a “task_struct” structure in Linux). The set of parameters may be used to control one or more characteristics associated with fetching data from memory, such as a number of streams that the prefetcher will track, a distance associated with a fetch, a window associated with a fetch, allowing a linear to exponentially increasing distance, and/or a size associated with a fetch.

The process600may also include executing606a control process (e.g., the kernel of an operating system) in a higher privileged mode than a mode to receive the set of parameters from the data structure and/or the system call. The control process may receive the set of parameters (e.g., input) from the data structure and/or the system call to as provided by the process executing in the lower privileged mode.

The process600may also include configuring608a prefetcher associated with the processor core to use the set of parameters for a process. The set of parameters may be applied to one or more registers controlling operation of the prefetcher. In some implementations, the set of parameters may be used to configure the prefetcher to fetch data from memory for the process that provided the input. The set of parameters may configure (or reconfigure) the prefetcher to control one or more characteristics associated with fetching data from memory and/or may change the one or more characteristics associated the fetching. In some implementations, the set of parameters may optimize fetching data from memory for a process based on a memory access pattern of the process.

FIG.7is a flow chart of an example of a process700for a configuring a prefetcher associated with a processor core and associated with a privilege mode. The process700may include tagging702a prefetcher associated with a processor core with a privilege mode for a first process that is executing in the processor core; resetting704the prefetcher based on a switch from the first process to a second process; and tagging706the prefetcher with a privilege mode for a second process that is executing in the processor core. For example, the prefetcher may be configured to contain data between first and second processes in a security context, so that information (e.g., a history of fetches) from one process is inaccessible to another process. For example, the process700may be executed in the system100shown inFIG.1, the system200shown inFIG.2, the system300shown inFIG.3, and/or the system400shown inFIG.4.

The process700may include tagging702a prefetcher associated with a processor core with a privilege mode for a first process that is executing in the processor core. The privilege mode for the first process may be broadcasted to one or more functional units in the processor core. The prefetcher may be configured to use a first set of parameters when fetching data from memory for the first process. The first set of parameters may be based on user input. The prefetcher may fetch data for the first process based on the first set of parameters. In some implementations, the prefetcher may include training for improving fetches for the first process (e.g., a trained state), analogous to machine learning, in the privilege mode.

The process700may also include resetting704the prefetcher based on a switch from the first process to a second process. For example, resetting may occur prior to a context switch from the first process to the second process. In some implementations, the context switch may trigger the reset to occur (e.g., a run time reset). In some implementations, reconfiguring the prefetcher with a second set of parameters may trigger the reset to occur. In other words, the prefetcher may detect a process change and reset in response to the process change (e.g., clear the history associated with the fetches). In some implementations, the prefetcher may be reset in order to contain data associated with the first process from the second process, so that information (e.g., a history of fetches) from the first process is inaccessible to the second process. For example, the trained state associated with fetching data for the first process may be inaccessible to the second process following the reset (e.g., the prefetcher may be cleared). In some implementations, the prefetcher may be reset in one clock cycle.

The process700may also include tagging706the prefetcher with a privilege mode for the second process that is executing in the processor core. The privilege mode for the second process may also be broadcasted to the one or more functional units in the processor core. In some implementations, the second process may carry over the privilege mode of the first process (e.g., execute in a privilege mode having the same settings as the first process). The prefetcher may be configured to use the second set of parameters when fetching data from memory for the second process. The second set of parameters may be based on user input. The prefetcher may fetch data for the second process based on the second set of parameters. In some implementations, the prefetcher may include training for improving fetches for the second process (e.g., a trained state), analogous to machine learning, in the privilege mode.

FIG.8is a block diagram of an example of a system800for generation and manufacture of integrated circuits. The system800includes a network806, an integrated circuit design service infrastructure810(e.g., integrated circuit generator), a field programmable gate array (FPGA)/emulator server820, and a manufacturer server830. For example, a user may utilize a web client or a scripting application program interface (API) client to command the integrated circuit design service infrastructure810to automatically generate an integrated circuit design based on a set of design parameter values selected by the user for one or more template integrated circuit designs. In some implementations, the integrated circuit design service infrastructure810may be configured to generate an integrated circuit design that includes the circuitry shown and described inFIGS.1-4.

The integrated circuit design service infrastructure810may include a register-transfer level (RTL) service module configured to generate an RTL data structure for the integrated circuit based on a design parameters data structure. For example, the RTL service module may be implemented as Scala code. For example, the RTL service module may be implemented using Chisel. For example, the RTL service module may be implemented using flexible intermediate representation for register-transfer level (FIRRTL) and/or a FIRRTL compiler. For example, the RTL service module may be implemented using Diplomacy. For example, the RTL service module may enable a well-designed chip to be automatically developed from a high level set of configuration settings using a mix of Diplomacy, Chisel, and FIRRTL. The RTL service module may take the design parameters data structure (e.g., a java script object notation (JSON) file) as input and output an RTL data structure (e.g., a Verilog file) for the chip.

In some implementations, the integrated circuit design service infrastructure810may invoke (e.g., via network communications over the network806) testing of the resulting design that is performed by the FPGA/emulation server820that is running one or more FPGAs or other types of hardware or software emulators. For example, the integrated circuit design service infrastructure810may invoke a test using a field programmable gate array, programmed based on a field programmable gate array emulation data structure, to obtain an emulation result. The field programmable gate array may be operating on the FPGA/emulation server820, which may be a cloud server. Test results may be returned by the FPGA/emulation server820to the integrated circuit design service infrastructure810and relayed in a useful format to the user (e.g., via a web client or a scripting API client).

The integrated circuit design service infrastructure810may also facilitate the manufacture of integrated circuits using the integrated circuit design in a manufacturing facility associated with the manufacturer server830. In some implementations, a physical design specification (e.g., a graphic data system (GDS) file, such as a GDSII file) based on a physical design data structure for the integrated circuit is transmitted to the manufacturer server830to invoke manufacturing of the integrated circuit (e.g., using manufacturing equipment of the associated manufacturer). For example, the manufacturer server830may host a foundry tape-out website that is configured to receive physical design specifications (e.g., such as a GDSII file or an open artwork system interchange standard (OASIS) file) to schedule or otherwise facilitate fabrication of integrated circuits. In some implementations, the integrated circuit design service infrastructure810supports multi-tenancy to allow multiple integrated circuit designs (e.g., from one or more users) to share fixed costs of manufacturing (e.g., reticle/mask generation, and/or shuttles wafer tests). For example, the integrated circuit design service infrastructure810may use a fixed package (e.g., a quasi-standardized packaging) that is defined to reduce fixed costs and facilitate sharing of reticle/mask, wafer test, and other fixed manufacturing costs. For example, the physical design specification may include one or more physical designs from one or more respective physical design data structures in order to facilitate multi-tenancy manufacturing.

In response to the transmission of the physical design specification, the manufacturer associated with the manufacturer server830may fabricate and/or test integrated circuits based on the integrated circuit design. For example, the associated manufacturer (e.g., a foundry) may perform optical proximity correction (OPC) and similar post-tape-out/pre-production processing, fabricate the integrated circuit(s)832, update the integrated circuit design service infrastructure810(e.g., via communications with a controller or a web application server) periodically or asynchronously on the status of the manufacturing process, perform appropriate testing (e.g., wafer testing), and send to a packaging house for packaging. A packaging house may receive the finished wafers or dice from the manufacturer and test materials and update the integrated circuit design service infrastructure810on the status of the packaging and delivery process periodically or asynchronously. In some implementations, status updates may be relayed to the user when the user checks in using the web interface, and/or the controller might email the user that updates are available.

In some implementations, the resulting integrated circuit(s)832(e.g., physical chips) are delivered (e.g., via mail) to a silicon testing service provider associated with a silicon testing server840. In some implementations, the resulting integrated circuit(s)832(e.g., physical chips) are installed in a system controlled by the silicon testing server840(e.g., a cloud server), making them quickly accessible to be run and tested remotely using network communications to control the operation of the integrated circuit(s)832. For example, a login to the silicon testing server840controlling a manufactured integrated circuit(s)832may be sent to the integrated circuit design service infrastructure810and relayed to a user (e.g., via a web client). For example, the integrated circuit design service infrastructure810may be used to control testing of one or more integrated circuit(s)832.

FIG.9is a block diagram of an example of a system900for facilitating generation of integrated circuits, for facilitating generation of a circuit representation for an integrated circuit, and/or for programming or manufacturing an integrated circuit. The system900is an example of an internal configuration of a computing device. The system900may be used to implement the integrated circuit design service infrastructure810, and/or to generate a file that generates a circuit representation of an integrated circuit design that includes the circuitry shown and described inFIGS.1-4.

The processor902can be a central processing unit (CPU), such as a microprocessor, and can include single or multiple processors having single or multiple processing cores. Alternatively, the processor902can include another type of device, or multiple devices, now existing or hereafter developed, capable of manipulating or processing information. For example, the processor902can include multiple processors interconnected in any manner, including hardwired or networked, including wirelessly networked. In some implementations, the operations of the processor902can be distributed across multiple physical devices or units that can be coupled directly or across a local area or other suitable type of network. In some implementations, the processor902can include a cache, or cache memory, for local storage of operating data or instructions. The system900can include components or units, such as a processor902, a bus904, a memory906, peripherals914, a power source916, a network communication interface918, a user interface920, other suitable components, or a combination thereof.

The memory906can include volatile memory, non-volatile memory, or a combination thereof. For example, the memory906can include volatile memory, such as one or more dynamic random access memory (DRAM) modules such as double data rate (DDR) synchronous DRAM (SDRAM), and non-volatile memory, such as a disk drive, a solid-state drive, flash memory, Phase-Change Memory (PCM), or any form of non-volatile memory capable of persistent electronic information storage, such as in the absence of an active power supply. The memory906can include another type of device, or multiple devices, now existing or hereafter developed, capable of storing data or instructions for processing by the processor902. The processor902can access or manipulate data in the memory906via the bus904. Although shown as a single block inFIG.8, the memory906can be implemented as multiple units. For example, a system900can include volatile memory, such as random access memory (RAM), and persistent memory, such as a hard drive or other storage.

The memory906can include executable instructions908, data, such as application data910, an operating system912, or a combination thereof, for immediate access by the processor902. The executable instructions908can include, for example, one or more application programs, which can be loaded or copied, in whole or in part, from non-volatile memory to volatile memory to be executed by the processor902. The executable instructions908can be organized into programmable modules or algorithms, functional programs, codes, code segments, or combinations thereof to perform various functions described herein. For example, the executable instructions908can include instructions executable by the processor902to cause the system900to automatically, in response to a command, generate an integrated circuit design and associated test results based on a design parameters data structure. The application data910can include, for example, user files, database catalogs or dictionaries, configuration information or functional programs, such as a web browser, a web server, a database server, or a combination thereof. The operating system912can be, for example, Microsoft Windows®, macOS®, or Linux®; an operating system for a small device, such as a smartphone or tablet device; or an operating system for a large device, such as a mainframe computer. The memory906can comprise one or more devices and can utilize one or more types of storage, such as solid-state or magnetic storage.

The peripherals914can be coupled to the processor902via the bus904. The peripherals914can be sensors or detectors, or devices containing any number of sensors or detectors, which can monitor the system900itself or the environment around the system900. For example, a system900can contain a temperature sensor for measuring temperatures of components of the system900, such as the processor902. Other sensors or detectors can be used with the system900, as can be contemplated. In some implementations, the power source916can be a battery, and the system900can operate independently of an external power distribution system. Any of the components of the system900, such as the peripherals914or the power source916, can communicate with the processor902via the bus904.

The network communication interface918can also be coupled to the processor902via the bus904. In some implementations, the network communication interface918can comprise one or more transceivers. The network communication interface918can, for example, provide a connection or link to a network, such as the network806shown inFIG.8, via a network interface, which can be a wired network interface, such as Ethernet, or a wireless network interface. For example, the system900can communicate with other devices via the network communication interface918and the network interface using one or more network protocols, such as Ethernet, transmission control protocol (TCP), Internet protocol (IP), power line communication (PLC), Wi-Fi, infrared, general packet radio service (GPRS), global system for mobile communications (GSM), code division multiple access (CDMA), or other suitable protocols.

A user interface920can include a display; a positional input device, such as a mouse, touchpad, touchscreen, or the like; a keyboard; or other suitable human or machine interface devices. The user interface920can be coupled to the processor902via the bus904. Other interface devices that permit a user to program or otherwise use the system900can be provided in addition to or as an alternative to a display. In some implementations, the user interface920can include a display, which can be a liquid crystal display (LCD), a cathode-ray tube (CRT), a light emitting diode (LED) display (e.g., an organic light emitting diode (OLED) display), or other suitable display. In some implementations, a client or server can omit the peripherals914. The operations of the processor902can be distributed across multiple clients or servers, which can be coupled directly or across a local area or other suitable type of network. The memory906can be distributed across multiple clients or servers, such as network-based memory or memory in multiple clients or servers performing the operations of clients or servers. Although depicted here as a single bus, the bus904can be composed of multiple buses, which can be connected to one another through various bridges, controllers, or adapters.

A non-transitory computer readable medium may store a circuit representation that, when processed by a computer, is used to program or manufacture an integrated circuit. For example, the circuit representation may describe the integrated circuit specified using a computer readable syntax. The computer readable syntax may specify the structure or function of the integrated circuit or a combination thereof. In some implementations, the circuit representation may take the form of a hardware description language (HDL) program, a register-transfer level (RTL) data structure, a flexible intermediate representation for register-transfer level (FIRRTL) data structure, a Graphic Design System II (GDSII) data structure, a netlist, or a combination thereof. In some implementations, the integrated circuit may take the form of a field programmable gate array (FPGA), application specific integrated circuit (ASIC), system-on-a-chip (SoC), or some combination thereof. A computer may process the circuit representation in order to program or manufacture an integrated circuit, which may include programming a field programmable gate array (FPGA) or manufacturing an application specific integrated circuit (ASIC) or a system on a chip (SoC). In some implementations, the circuit representation may comprise a file that, when processed by a computer, may generate a new description of the integrated circuit. For example, the circuit representation could be written in a language such as Chisel, an HDL embedded in Scala, a statically typed general purpose programming language that supports both object-oriented programming and functional programming.

In an example, a circuit representation may be a Chisel language program which may be executed by the computer to produce a circuit representation expressed in a FIRRTL data structure. In some implementations, a design flow of processing steps may be utilized to process the circuit representation into one or more intermediate circuit representations followed by a final circuit representation which is then used to program or manufacture an integrated circuit. In one example, a circuit representation in the form of a Chisel program may be stored on a non-transitory computer readable medium and may be processed by a computer to produce a FIRRTL circuit representation. The FIRRTL circuit representation may be processed by a computer to produce an RTL circuit representation. The RTL circuit representation may be processed by the computer to produce a netlist circuit representation. The netlist circuit representation may be processed by the computer to produce a GDSII circuit representation. The GDSII circuit representation may be processed by the computer to produce the integrated circuit.

In another example, a circuit representation in the form of Verilog or VHDL may be stored on a non-transitory computer readable medium and may be processed by a computer to produce an RTL circuit representation. The RTL circuit representation may be processed by the computer to produce a netlist circuit representation. The netlist circuit representation may be processed by the computer to produce a GDSII circuit representation. The GDSII circuit representation may be processed by the computer to produce the integrated circuit. The foregoing steps may be executed by the same computer, different computers, or some combination thereof, depending on the implementation.

In a first aspect, the subject matter described in this specification can be embodied in a method that includes reconfiguring a prefetcher associated with a processor core responsive to a context switch where the processor core changes from executing a first process to a second process. In some implementations, reconfiguring the prefetcher includes updating a register controlling an operation of the prefetcher from a first set of parameters associated with the first process to a second set of parameters associated with the second process. In some implementations, the second set of parameters is based on input from a process executed in a user mode. In some implementations, the register is located to enable updating the register with the second set of parameters after using the prefetcher with the first set of parameters during run time. In some implementations, the second process is a new process, and wherein the second set of parameters is a default set of parameters. In some implementations, reconfiguring the prefetcher resets the prefetcher to prevent the second process from accessing data associated with the first process. In some implementations, reconfiguring the prefetcher comprises a kernel of an operating system executing in a higher privileged mode receiving input from a data structure and reconfiguring the prefetcher based on the input, wherein the data structure is writeable by a process when the process is executing in a lower privileged mode associated with a user mode. In some implementations, reconfiguring the prefetcher comprises the first process reconfiguring the prefetcher for the second process. In some implementations, reconfiguring the prefetcher comprises the second process reconfiguring the prefetcher for the second process. In some implementations, reconfiguring the prefetcher comprises resetting training data associated with the prefetcher. In some implementations, the method further comprises tagging the processor core with a privilege mode method with the first process and resetting the prefetcher, in connection with the context switch, to clear a history associated with the first process.

In a second aspect, the subject matter described in this specification can be embodied in a system that includes: a processor core; and a prefetcher associated with the processor core, wherein the prefetcher is reconfigured responsive to a context switch where the processor core changes from executing a first process to a second process. In some implementations, reconfiguring the prefetcher includes updating a register controlling an operation of the prefetcher from a first set of parameters associated with the first process to a second set of parameters associated with the second process. In some implementations, the second set of parameters is based on input from a process executed in a user mode. In some implementations, the register is located to enable updating the register with the second set of parameters after using the prefetcher with the first set of parameters during run time. In some implementations, the second process is a new process, and wherein the second set of parameters is a default set of parameters. In some implementations, the prefetcher associated with the processor core is a first prefetcher associated with a first processor core, and further comprising migrating the second process to a second processor core and updating a register controlling an operation of a second prefetcher associated with the second processor core to the second set of parameters associated with the second process. In some implementations, reconfiguring the prefetcher resets the prefetcher to prevent the second process from accessing data associated with the first process. In some implementations, reconfiguring the prefetcher comprises a kernel of an operating system executing in a higher privileged mode receiving an input from a data structure and reconfiguring the prefetcher based on the input, wherein the data structure is writeable by a process when the process is executing in a lower privileged mode associated with a user mode. In some implementations, reconfiguring the prefetcher comprises the first process reconfiguring the prefetcher for the second process. In some implementations, reconfiguring the prefetcher comprises the second process reconfiguring the prefetcher for the second process. In some implementations, reconfiguring the prefetcher comprises resetting training data associated with the prefetcher. In some implementations, the processor core is tagged with a privilege mode associated with the first process and the prefetcher is reset, in connection with the context switch, to clear a history associated with the first process.

In a third aspect, the subject matter described in this specification can be embodied in a method that includes reconfiguring a prefetcher associated with a processor core responsive to a context switch where the processor core changes from executing a first process to a second process, where the prefetcher is reconfigured based on input from a third process executed in a user mode. In some implementations, the second process is a same process as the third process. In some implementations, reconfiguring the prefetcher includes updating a register controlling an operation of the prefetcher from a first set of parameters associated with the first process to a second set of parameters associated with the second process. In some implementations, the second set of parameters is based on input from a process executed in a user mode. In some implementations, the register is located to enable updating the register with the second set of parameters after using the prefetcher with the first set of parameters during run time. In some implementations, the second process is a new process, and wherein the second set of parameters is a default set of parameters. In some implementations, reconfiguring the prefetcher resets the prefetcher to prevent the second process from accessing data associated with the first process. In some implementations, reconfiguring the prefetcher comprises a kernel of an operating system executing in a higher privileged mode receiving input from a data structure and reconfiguring the prefetcher based on the input, wherein the data structure is writeable by a process when the process is executing in a lower privileged mode associated with a user mode. In some implementations, reconfiguring the prefetcher comprises the first process reconfiguring the prefetcher for the second process. In some implementations, reconfiguring the prefetcher comprises the second process reconfiguring the prefetcher for the second process. In some implementations, reconfiguring the prefetcher comprises resetting training data associated with the prefetcher. In some implementations, the method further comprises tagging the processor core with a privilege mode method with the first process and resetting the prefetcher, in connection with the context switch, to clear a history associated with the first process.