PC-based computer permissions

Abstract

A license model for a processor is disclosed that is based on a memory address accessed by an instruction and a program counter for the instruction. The permissions may be stored in a permission table and indexed using a memory address of the instruction and an address of a memory location accessed by the instruction. In some cases, those indices may be obtained from a page table. These permissions may be used in conjunction with other permissions, such as permissions based on whether the instruction belongs to a particular group of instructions. The permission may identify from a program counter value which of a plurality of instruction groups of a processor instruction set architecture (ISA) are permitted to execute. Thus, the group of instructions of the instruction may be compared to the permitted group of instructions to determine whether the instruction has execution permission.

Description

background Technical Field

[0002] Embodiments described herein relate to licensing in a processor. Background Art

[0003] Processors, also known as central processing units (CPUs), are the core components of computing devices that perform a wide range of computing tasks. They are responsible for executing instructions, managing data, and controlling the overall operation of computer systems. Processors are found in a variety of devices, including personal computers, laptops, smartphones, servers, and embedded systems, powering the functionality and performance of these devices.

[0004] Permissions play a key role in the operation of a processor. The ability of a processor to perform tasks efficiently and securely relies on the concept of permissions. Permissions determine the actions and resources that different components within the system can access, thereby ensuring the integrity, confidentiality, and availability of data and functionality. By enforcing permissions, the processor ensures that only authorized entities can perform specific operations or access sensitive data, thereby preventing unauthorized or malicious activities. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The following detailed description refers to the accompanying drawings, which are now briefly described.

[0006] Figure 1 is a block diagram of one embodiment of a system including a processor coupled to a system memory.

[0007] FIG. 2A to FIG. 2B is a block diagram of the permission table.

[0008] Figure 3 It is a block diagram of the secondary execution privilege table.

[0009] Figure 4A An example of a permissions evaluation for a memory access instruction is depicted.

[0010] Figure 4B An example of a permissions evaluation for a branch instruction is depicted.

[0011] Figure 4C An example of a license evaluation for instruction group based licensing is depicted.

[0012] Figure 5A An example of a pattern-based permissions evaluation of memory access instructions is depicted.

[0013] Figure 5B An example of a pattern-based permissive evaluation for a branch instruction is depicted.

[0014] Fig. 6Ais a block diagram of one embodiment of a circuit configured to perform PC-based licensing evaluation on instructions.

[0015] Figure 6B yes Fig. 6A 0046] A block diagram of one embodiment of a primary permission lookup table within the circuit depicted in .

[0016] Figure 6C Is configured as management Fig. 6A 00146] A block diagram of one embodiment of a circuit for executing a mode of operation in the circuit depicted in FIG.

[0017] Fig. 7A is a block diagram illustrating one example of PC-based virtual address permissions within a virtual address space.

[0018] Figure 7B is a block diagram illustrating another example of PC-based virtual address permissions within a virtual address space in two different execution modes.

[0019] Fig. 8A is a flow chart of one embodiment of a method for enforcing permissions for memory access instructions.

[0020] Figure 8B is a flow chart of one embodiment of another method for enforcing permissions for memory access instructions.

[0021] Fig.9A is a flow chart of one embodiment of a method for enforcing instruction group permissions.

[0022] Fig. 9B is a flow chart of one embodiment of another method for enforcing instruction group permissions.

[0023] Fig.10 is a block diagram illustrating an exemplary computing device for implementing the disclosed technology.

[0024] Fig.11 are diagrams illustrating exemplary applications of systems and devices employing the disclosed technology.

[0025] Fig.12 is a block diagram illustrating an exemplary computer-readable medium storing circuit design information for implementing a device employing the disclosed techniques. DETAILED DESCRIPTION

[0026] Current computer processors typically execute with address translation enabled: the addresses of instructions fetched by the processor and the addresses of data accessed by memory access instructions (such as loads and stores) are virtual addresses, which are then mapped to physical addresses that actually identify the physical memory locations where the instructions and data are stored. The mapping is performed at a specified granularity, often referred to as a "page." Page sizes vary—common sizes include 4KB, 8KB, etc.; 1MB, 2MB, and 4MB page sizes may also be used. In general, however, in various embodiments, any page size may be used. Some instruction set architectures (ISAs) define the supported page sizes, while other instruction set architectures may leave the definition of the virtual-to-physical address translation mechanism up to various specific implementations.

[0027] A collection of software managed page tables defines virtual to physical address mappings at page granularity. The virtual address is used to locate an entry in the page table with the physical page number of the page. The least significant bits of the virtual address define the offset within the page and are not translated. After translation, the remaining virtual address bits are replaced by the physical page number. Frequently stored virtual to physical translations can be cached in translation lookaside buffers (TLBs) throughout the system.

[0028] This address translation provided by the page table provides isolation between different programs running on the same system. It also permits the use of a virtual address space that is larger than the physical address space by paging data into and out of various types of backing storage devices (e.g., non-volatile storage devices, disk drives, solid-state drives, etc.). In addition, address translation allows memory protection at a page granularity level.

[0029] The page table entry for a given page may include permissions that control access to the page. For example, page table permissions may include execute, read, and write permissions. If a page has execute permission, instructions are allowed to execute in the page. Therefore, if the program counter (PC) of the processor is set to an address within the page, the processor will allow instruction fetching and execution from the page. If the page does not have execute permission, attempts to execute instructions from the page are not allowed, and the processor signals an exception. If the page has read permission, memory access instructions are allowed to read data from the page (e.g., executable loads). If the page does not have read permission, memory access instructions that attempt to read the page will cause an exception to the processor. Similarly, pages with write permission can be written by memory access instructions (e.g., storage). Conversely, writing to pages that do not have write permission by memory access instructions will cause an exception.

[0030] Additionally, some instructions in the ISA may be reserved for execution at a specific privilege level, which is usually determined when the instruction is executed. Most software is executed at a relatively low privilege level, thereby preventing the software from accessing and / or updating key processor states and other protected resources (helping to ensure security in the system). In many cases, such software cannot execute instructions that are restricted to a higher privilege level. On the other hand, the part of the operating system that accesses / changes this state can be executed at a higher privilege level. The number of privilege levels and the instructions that can be executed at each privilege level are different because of the differences in the ISA.

[0031] Because many of the permissions are stored in page tables and / or are restricted to access at higher privilege levels, dynamically changing levels is slow, especially when cached copies of translations are stored in multiple TLBs throughout a computer system. To change page permissions in such a scenario, any corresponding TLB entries would need to be invalidated, which involves synchronization of processors in the system. The TLB can then be reloaded from memory with the updated translations (including the permissions update, which may be the only information that is changed).

[0032] For example, in the case of page table based permissions, the permissions are also at a coarse-grained level such that all instructions at a given page may share the same permissions. These mechanisms are not sufficient to support certain types of software security models.

[0033] The present disclosure describes the modification of permissions using one or more permission tables based on the PC of an instruction. For example, in one embodiment, memory access instructions such as load and store can access a permission table based on a primary permission table index and a secondary permission table index. The primary permission table index can be provided from a converted page table entry that provides a page being accessed (e.g., a location specified by a load instruction). The secondary permission table index can be provided from a converted page table entry that provides the PC of the instruction. The processor can be configured to combine the primary permission table index and the secondary permission table index to generate a combined permission table index. The combined permission table index can be used to access the permission table to obtain permissions for memory access. Therefore, different memory access instructions (stored in, for example, different pages) can have different permissions for a given memory address. This example allows different processes (executed from different pages) that share the same virtual address space to have different permissions for a given memory address. For example, a first process can have read and write access to a memory address, while a second process can have read-only access to a memory address.

[0034] In one embodiment, the primary permission table index and the secondary permission table index may be combined via concatenation to form a combined permission table index. Other embodiments may use other types of operations, such as arithmetic operations (e.g., addition, subtraction, etc.) or logical operations (e.g., XOR, shift, etc.).

[0035] The present disclosure contemplates various possible ways to implement the final permission for a memory access instruction that accesses a specific address. In one embodiment, a permission table may store permissions for memory access instructions to access addresses. In an alternative embodiment, a permission table may store values ​​that can be used to reduce the primary permissions assigned to the address being accessed. For example, a page table entry that converts the address being accessed may store a primary permission, and the permission from the permission table may include a mask that is bitwise ANDed with the primary permission to determine the final permission. The zero bits in the mask ensure that permissions (e.g., read, write, or execute) are not granted. On the other hand, the one bits in the mask keep the primary permission unchanged (e.g., granted or not granted). In another embodiment, the primary permission table may be accessed using a primary permission index, and the secondary permission table may be accessed using a secondary permission index. The resulting permission may be bitwise ANDed as described above. In yet another embodiment, the primary permission table may be accessed using a primary permission index, and the secondary permission table may be accessed using a combined permission table index.

[0036] In various specific implementations, the disclosed techniques can also be used for fine-grained control of branch behavior. For example, a branch at PC1 with a target address at PC2 can be controlled based on a primary permission table index corresponding to PC1 and a secondary permission table index corresponding to PC2. Other means (e.g., primary permission table index corresponding to PC2 and secondary permission table index corresponding to PC1) can also be used to obtain similar results.

[0037] It is also envisioned that fine-grained control of execution privileges. For example, a secondary execution privilege table can be implemented in a processor, or another field in a page table entry can specify a secondary execution privilege. The secondary execution privilege may include execution permission or non-execution permission for a subset of instructions in the ISA. For example, some or all instructions in the instruction may be divided into subsets, and permission may be controlled on a subset-by-subset basis. These subsets (or instruction groups or IGs) may include privileged instructions and / or multiple subsets of privileged instructions, instructions that read or write special registers (even if they are not privileged) and system call instructions (for example, system call instructions may even be their own subsets). Secondary execution privileges may be used to independently define and control any combination of subsets of instructions. In one embodiment, secondary execution privileges may be used to reduce primary execution privileges. In this specific implementation, if the primary execution privilege is not executed, no matter how the secondary execution privilege is, no instruction can be executed. On the contrary, the primary execution privilege may indicate executable, and the second execution privilege is not executed, thereby making the corresponding instruction unable to execute. Note that if the processor is not executing in privileged mode, no privileged instructions can be executed, even if one or more subsets are indicated as executable in the secondary execution privileges. In one embodiment, at least some instructions are not controlled via the secondary execution privileges. That is, some instructions may not be included in any subset and may be executable as long as the primary permissions include execution.

[0038] The permission table can be implemented in any desired manner. For example, the permission table can be in a memory (e.g., dynamic random access memory (DRAM)), a local memory on a processor (e.g., static RAM (SRAM)), a processor register, etc. Similarly, the secondary execution privilege table can be implemented in any of the above-mentioned ways. In one embodiment, the secondary execution privilege table can be shared with the permission table. In one embodiment, there can be different permission tables for different privilege levels, and / or there can be different permission tables for different stages.

[0039] Figure 1 1 is a block diagram of one embodiment of a system 100 including a processor 10. In the depicted embodiment, the processor 10 includes an execution core 12 coupled to a register file 14. As shown, the execution core 12 may include a memory management unit circuit (MMU) 18, which in turn may include a control circuit 24 coupled to a translation lookaside buffer circuit (TLB) 26, a permission table 20, and a secondary execution privilege table 22. The processor 10 may be configured to execute a program in a manner that is consistent with the system's implementation. Figure 1 3 is shown coupled to a memory 30, which may store a page table 28 including a set of page tables during use. A portion of the page table 28 is shown in an exploded view 32 and includes a set of page table entries, such as entries 34A-34B.

[0040] Processor 10 may represent a general purpose processor that performs computing operations. For example, processor 10 may be a central processing unit (CPU), such as a microprocessor, a microcontroller, an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA). Processor 10 may be a stand-alone component, or may be integrated onto an integrated circuit with other components (e.g., other processors, or other components in a system on a chip (SOC)). In some cases, processor 10 may be a component in a multi-chip module (MCM) with other components.

[0041] As shown, the processor 10 may include an execution core 12. The execution core 12 may be configured to execute instructions defined in the ISA implemented by the processor 10. The execution core 12 may have any suitable microarchitecture features and specific implementation features as needed. For example, the execution core 12 may include a superscalar or scalar specific implementation. The execution core 12 may include an ordered or unordered specific implementation, and a speculative or non-speculative specific implementation. The execution core 12 may include any combination of the above features. In some embodiments, the specific implementation may include microcode. The execution core 12 may include various execution units, each of which is configured to perform various types of operations (e.g., integer, floating point, vector, multimedia, load / store, etc.). Further, the execution core 12 may include different numbers of pipeline stages and various other performance enhancement features, such as branch prediction. Similarly, the execution core 12 may include one or more of an instruction decoding unit, a scheduler or reservation station, a reorder buffer, a memory management unit, an I / O interface, etc.

[0042] The MMU 18 may include a control circuit 24 configured to perform address translation, access the TLB 26 for a given virtual address to determine whether the address hits in the TLB 26, and if not, perform a table walk in the page table 28 to locate the translation. The TLB 26 may cache the physical page number (PPN) of the translation, as well as various other data from the translation, such as permissions, permission table indexes, secondary execution privileges or indexes, etc. The permission table 20 may be a permission table as described above, and in some embodiments may be indexed by a combined permission table index as also discussed above. In other embodiments, there may be multiple permission tables 20 accessed by various separate indexes or combined indexes as also discussed previously. The secondary execution privilege table 22 may also be the secondary execution privilege table discussed above. Other embodiments may not include the secondary execution privilege table 22. For example, the secondary execution privileges may be included immediately in the page table 28 and cached in the TLB 26. Additionally, the secondary execution privileges may be included in the permission table 20 together with the primary permissions, so that all permissions are stored in a single permission table.

[0043] TLB 26 may have any suitable configuration and size. In some embodiments, TLB 26 may represent multiple TLBs (e.g., an instruction TLB accessed by a PC during instruction fetch, and a data TLB accessed by a memory address during execution of a memory access instruction). TLB 26 may also have multiple levels (e.g., a first level TLB backed up by a second level TLB, etc.).

[0044] Register file 14 may include a set of registers that may be used to store operands for various instructions. Register file 14 may include registers of various data types based on the type of operands that execution core 12 is configured to store in registers (e.g., integer, floating point, multimedia, vector, etc.). Register file 14 may include architected registers (i.e., those registers specified in an ISA implemented by processor 10). Alternatively or in addition, register file 14 may include physical registers (e.g., if register renaming is implemented in execution core 12).

[0045] Instructions are executable entities defined in the ISA implemented by the processor 10. There are various ISAs (e.g., x86 ISA originally developed by Intel, ARM from ARM Holdings, Power and PowerPC from IBM / Motorola, etc.). ISA defines various aspects of its constituent instructions, including their encoding in memory, their operations, and their impact on registers, memory locations, and / or other processor states. A given specific implementation of ISA can directly execute each instruction, but its form can be changed by decoding and other manipulations in the processor hardware. Another specific implementation can decode at least some instructions into multiple instruction operations for execution by the execution unit in the processor 10. In some embodiments, some instructions can be microcoded. Therefore, the phrase "instruction operation" is used herein to refer to the operation that the execution unit in the processor 10 / execution core 12 is configured to perform as a single entity. Instructions can have a one-to-one correspondence with instruction operations, and in some cases, instruction operations can be instructions (possibly modified to the form inside the processor 10 / execution core 12). Instructions can also have a one-to-one (one-to-many) correspondence with instruction operations. Instruction operations can also be referred to as "operations".

[0046] In various embodiments, page table entries 34A-34B may store a physical page number (PPN) and various other translation-related data (in Figure 1). The page table entries 34A-34B may also store a permission table index (PTI) 38, which is a value used to select a particular entry in the permission table. The PTI may be a primary page table index if the translation is to the data address of a memory access instruction, or a secondary page table index if the translation is to the PC of an instruction. The page table entries 34A-34B may also store a secondary execution privilege table index (SEPI) 41. In some embodiments, the page table entries 34A-34B may directly store the secondary execution privileges (SEP). Although not drawn, the page table 28 may also include the primary permissions themselves. Thus, in various embodiments, the page table 28 may include indications of the primary permissions and the secondary permissions—these indications may take the form of the permissions themselves or indexes that can be used to locate the permissions in the permission table.

[0047] Figure 2A 38 is an example of an embodiment of permission table 20. As shown, permission table 20 may include multiple entries indexed by permission table index 38. In various embodiments, the permission table index may variously be a primary permission table index, a secondary permission table index, or a combined permission table index. Exemplary permission table entry 40 is shown in an exploded view and includes read permission, write permission, and execute permission. If permission table index 38 is a primary permission table index or a combined permission table index, permission table entry 40 may store the actual permission. If permission table index 38 is a secondary permission table index, permission table entry 40 may store a mask for masking the actual permission. Alternatively, if different permission tables provide the actual permission, reading permission table 20 with a combined permission table index may also provide a mask.

[0048] Figure 2B is an example of a permission table 20 that allows permissions to be specified according to two "dimensions" or properties. As shown, permission table 200 is configured to store read, write, and execute permissions for a virtual address region. Figure 2B In the particular implementation shown, a particular set of permissions is accessed using a first index 210 and a second index 220. In other implementations, indexes 210 and 220 may be combined into a single index; Figure 2B Two indexes are shown in order to demonstrate the more granular nature of the permissions.

[0049] In the depicted embodiment, the use of two indexes allows permissions to be specified for two different (and independent) virtual address (VA) regions associated with a single instruction. Consider that the processor 10 executes an instruction having a PC value in VA region 212A and accessing data stored in VA region 222D. Permission for such an instruction can be accessed by selecting the first index 210 of region 212A and selecting the second index 220 of VA region 222D. As shown, region 222 has read, write and execute permissions. However, other regions within the VA space may have different permissions: region 222C has read-only permission, while region 222E has read-write permission. The result of using multiple indexes based on different properties / dimensions is that code in a given region of the VA space (e.g., a thread or part of a thread specified by index 210) may have different memory access permissions for different memory locations (specified by index 220).

[0050] As indicated, indexes 210 and 220 are independent of each other. Consider a VA space. Index 210 can be used to select any area within the space. In such an area (e.g., area 222C), index 220 can also be used to address the entire VA space again, so that memory permissions for the entire VA space can be defined for a specific code segment. By making indexes 210 and 220 independent of each other, different permissions for the same memory location can be given to different code portions. In some specific implementations, table 200 can be considered a two-dimensional table. It should be noted that in different embodiments, first index 210 and second index 220 can be a primary index and a secondary index, or vice versa.

[0051] Figure 3 41. The secondary execution privilege table 22 may include multiple entries indexed by the secondary execution privilege index (SEPI) 41. The exemplary secondary execution privilege table entry 42 is shown in an exploded view. The entry 42 includes execution permissions for each instruction group (e.g., instruction group 1 (IG1), instruction group 2 (IG2), up to instruction group N (IGN)). In some instances, various instruction groups (IGs) may have execution permissions, while other instruction groups may not have execution permissions. In other instances, all IGs may have execution permissions.

[0052] The use of multiple licensing dimensions is now described in more detail with respect to FIGS. 4-5 .

[0053] Figure 4A4 is a block diagram of one embodiment of a permission evaluation 400 for a memory access instruction 402. As shown, the diagram depicts the use of two different virtual addresses (VAs) 404 to find permissions 420 for executing an instruction 402 (which includes a PC with VA 404A) that accesses a target location (which has VA 404B). This approach allows, for example, a given memory location to have different access permissions for different code portions.

[0054] As shown, PC 401 is the PC value of processor 10 corresponding to instruction 402. PC 401 specifies a PC virtual address 404A for finding an execution permission 420A for instruction 402. In the specific implementation shown, PC VA 404A can be used to find both permissions 420A and 420B. Memory access instruction 402 can be executed by processor 10 to load data from memory. As shown, instruction 402 includes an opcode 402A identifying a specific instruction and operands 402B to 402C accessed by instruction 402 (note that other instructions may have more or less operands). (Generally speaking, operands may include addresses, constants, registers, etc.). In the depicted example, opcode 402A indicates an ARM LDR instruction, operand 402C indicates that the VA (i.e., VA 404B) of the location accessed by the instruction is stored in X1, and operand 402B specifies the destination register of the data accessed at target VA 404B.

[0055] The page table 28 is configured to receive a virtual address input and output a corresponding index that can be used to access a lookup table (LUT). Figure 4A 404B, page table 28 outputs a primary index 406A that can be used to access LUT 410 to determine the execution permissions 420A for instruction 402. Separately, in response to receiving VA 404B, page table 28 outputs a primary index 406B that can be used to access LUT 410 to determine the primary or base memory permissions 416 for target VA 404B. In some embodiments, any of the disclosed LUTs, such as LUT 410, can be implemented as one or more registers or as a content addressable memory (CAM).

[0056] As noted, it may be desirable to be able to specify a more granular memory permission for target VA 404B based on PC VA 404A. To achieve this, two indexes may be used to access LUT 412 storing memory permission masks, one of the two indexes being selected using VA 404A, and the other of the two indexes being selected using VA 404B. Thus, different masks may be specified for a given program area and a given memory destination. Therefore, in some embodiments, LUT 412 may be implemented as a two-dimensional table. It should be understood that primary indexes 406A and 406B may be used to access LUT 412. However, the use of different secondary indexes 408A and 408B allows access to LUT 412 (that is, primary index 406 and secondary index 408 may have different number of bits) potentially with a granularity different from LUT 410. In the depicted embodiment, secondary indexes 406A and 406B are used to retrieve memory permission masks 418 from LUT 412.

[0057] Primary license 416 is the base memory permission for VA 404B for a given program executing on processor 10. In some implementations, primary license 416 may be the maximum possible permission for any program executing on processor 10. Further permission restrictions may be implemented via secondary licenses.

[0058] Program developers may desire, for example, to allow a first instruction set to read / write specific program data while preventing a second instruction set from accessing the data. This can be achieved using a secondary index 408, which is provided to a LUT 412 to output a memory permission mask 418. The use of secondary indexes 408A to 408B allows specific permissions to be set for each combination of program location and memory location. For example, a compiler developer may want a linker routine (within a certain PC value range) to be able to read and write compiler metadata (at a specific memory location set), but also want the same linker routine to only be able to read (and not modify) the code generated by other instructions of the compiler (at different memory location sets). This can be achieved using an independent index 408 and LUT 412.

[0059] Once determined, operation 419 may be used to combine (e.g., by a bitwise AND operation) the primary permissions 416 and the permission mask 418 to output a memory access permission 420B that reflects permissions from both the source VA 404A and the target VA 404B. By not setting certain bits of the permission mask 418, the primary permissions 416 may be reduced on an as-needed basis. Thus, the processor 10 (e.g., via the CTL 24) may use both the execution permission 420A and the memory access permission 420B to determine not only whether the instruction 402 is permitted to execute, but also whether the instruction 402 is permitted to access a particular target VA 404B specified in the instruction. In some embodiments, the execution permission 420A may be checked during an instruction decode phase of the processor 10 prior to the execution phase, while the memory access permission 420B may be checked prior to the memory access phase (e.g., during an operand fetch phase or an execution phase). If the permission 420A or 420B does not indicate authorization, the processor 10 may prevent execution and instead signal an exception.

[0060] Note that in other embodiments, entry 34 of PT 28 may include a primary index and the secondary permission immediately following it (as opposed to storing the secondary index itself), thereby resulting in indirection for only the primary permission.

[0061] For example, the licensed code may assign a primary index and a secondary index to each of the OS code, OS data, and kernel data. In such an assignment, an OS code region may be given a primary index 406A that is generally evaluated as execution, but is given a source secondary index 408A that interacts with a different target secondary index 408B in a different manner. The secondary index 408A for the OS code may be combined with a first possible secondary index 408B (e.g., for OS data) to output a mask 418B that allows execution at a particular memory location. Alternatively, the secondary index 408A for the OS code may be combined with a second possible secondary index 408B (e.g., for kernel data) to disallow execution at a particular memory location.

[0062] Figure 4A 1 illustrates that a single instruction can have multiple permissions associated with it - in this case, execution permissions and memory access permissions. With respect to memory access permissions, this can be based on two different dimensions or properties, such as the VA of the PC of the instruction itself and the VA of the memory location being accessed. Similar permission determinations exist for other types of instructions, such as branch instructions. As will be seen with respect to Figure 4B As described, permissions may define, for example, whether a branch instruction is permitted to fetch a target instruction. And if the branch target itself is a memory access instruction, permissions may define whether the target instruction is permitted to access a specified memory location.

[0063] Figure 4B 442 is a block diagram of one embodiment of a series of permission evaluations 430 for a branch instruction 432, whose target (instruction 442) is itself a memory access instruction. As shown, evaluations 430 use various VAs as inputs to a LUT, which is then accessed to determine permissions 460. In a first example, branch permissions 460A determine whether instruction 432 is permitted to branch to target instruction 442. Additionally, target execution permissions 460B specify whether target instruction 442 is permitted to execute. Finally, target data permissions 460C specify whether target instruction 442 is permitted to access a specified memory location. Note that execution permissions may have already been determined for instruction 432; therefore, in Figure 4B This process is not depicted.

[0064] As shown, branch instruction 432 is executed at PC2 431 corresponding to VA 434. Instruction 432 has an opcode 432A indicating an ARM BR instruction and includes operand 432B pointing to register X1 which stores the target address of the branch (i.e., target instruction 442). Target instruction 442 is executed at PC2 441 corresponding to VA 444A. Instruction 442 has an opcode 442A indicating an ARM LDR memory instruction and includes operands 442B to 442C. Operand 442B specifies register X2 as the destination of the load operation, while operand 442C specifies register X3 which stores the target memory location (with VA 444B).

[0065] Branch permission 460A is determined using information from both instructions 432 and 442. Primary memory permission 456A is determined from LUT 410 based on primary index 446A obtained from page table 28 using VA 444A (the PC of instruction 442). (This operation is similar to that described above with respect to Figure 4A 44A.) Simultaneously, memory permission mask 458A is determined from LUT 412 using secondary indexes 438 and 448A. Secondary index 438 is obtained from PT 28 using VA 434 (a primary index, not depicted, may also be obtained from the same entry in PT 28 to determine execution permission for instruction 432). Similarly, secondary index 448A is obtained from PT 28 using VA 444A. Primary permission 456A and mask 458A are then combined (e.g., bitwise ANDed) in operation 459A to output branch permission 460A. Thus, information from both branch instruction 432 and target instruction 442 may be used to verify that the branch is permitted.

[0066] Note that it can also be similar to Figure 4AThe described manner of determining the execution permission 420A uses the primary index 446A to determine the execution permission 460B for the instruction 442 from the LUT 410 .

[0067] With about Figure 4A Memory access permissions 460C for instruction 442 are determined in a manner similar to that described for permissions 420B in operation 459B. Specifically, permissions 460C are determined using information derived from both VA 444A (the PC of instruction 442) and VA 444B (the memory location addressed by instruction 442). Primary memory permissions 456B are determined from LUT 410 based on primary index 446B obtained from page table 28 using VA 444B (the PC of the target of instruction 442). Simultaneously, memory permission mask 458B is determined from LUT 412 using secondary indexes 448A-448B. Note that secondary index 448A has been retrieved from PT 28 in the context of determining memory permissions 460A. Secondary index 448B is obtained from PT 28 using VA 444B. Primary permissions 456B and mask 458B are then combined (e.g., bitwise ANDed) in operation 459B to output memory access permissions 460C.

[0068] Once the permissions 460 are obtained, the permissions may be evaluated at different stages of the execution pipeline of the processor 10. In some embodiments, the processor 10 may evaluate the permissions 460A before the fetch stage of the branch instruction 432 to ensure that the fetch of the target instruction 442 is permitted. If the fetch of the branch is permitted, the processor 10 may evaluate the permissions 460B before the execute stage of the memory instruction 442 to ensure that the instruction is permitted to execute. Similarly, the processor 10 may evaluate the permissions 460C at or before the memory stage of the instruction 442 to determine whether access to the memory at VA 444B is permitted. Alternatively, all permissions 460A to 460C may be evaluated before executing the instruction 432. If any of the permissions 460A to 460C are not permitted, the processor 10 may prevent the execution of both instructions 432 and 442 and signal an exception instead.

[0069] Please note that for Figure 4A and Figure 4B In both cases, multiple table accesses are used to retrieve the appropriate execution permissions and memory access permissions. Alternatively, the input VAs and output permissions may be cached for easier access in a TLB (e.g., TLB 26). In other embodiments, the indexes associated with the instruction (e.g., indexes 406A and 408A) may be stored directly as fields of the PC, rather than being retrieved from the PT.

[0070] Figure 4C4 is a block diagram depicting one embodiment of an instruction group evaluation 470. As shown, instruction 471 and VA 474 (available from the instruction's PC) are inputs to group circuit 473 and PT 28 to generate instruction group (IG) permission 490. Note that in some embodiments, evaluation 470 may be implemented independently of evaluations 400 and 430. However, in other embodiments, evaluation 470 may be used in conjunction with other disclosed evaluations.

[0071] The VA 474 of the instruction is provided to PT 28 to obtain an index 478, which in turn is used to select a corresponding entry 42 from table 41. Entry 42 stores permissions indicating which IGs the instruction at that VA is permitted to execute. Index 478 is similar to FIG. 4A to FIG. 4B The index described in .

[0072] Index 478 may be obtained in a different manner than shown. In some embodiments, the PC of instruction 471 may store index 478 directly, which would allow the index to be used directly without accessing PT 28. As an alternative, table 41 may be indexed similarly to other disclosed LUTs.

[0073] Group circuit 473 is configured to determine a corresponding IG 480 for instruction 471. In some embodiments, the assignment of ISA instructions to IGs may be predetermined and unmodifiable (e.g., hardwired in group circuit 473). In other embodiments, the assignment in group circuit 473 is modifiable (e.g., by an operating system or other authorized program).

[0074] In one embodiment, IG 480 is output by group circuit 473 as a bit vector in which the fields corresponding to the determined IG of instruction 471 are set and the remaining fields are not set. In this way, IG 480 can be ANDed with table entry 42. If corresponding values ​​in table entry 42 and IG 480 (i.e., the IG group corresponding to the IG of instruction 471) are both set, execution of instruction 471 is permitted, as indicated by IG permission 490.

[0075] In some embodiments, circuit 473 is implemented as a LUT with an opcode input (e.g., in instruction 471) and a corresponding IG 480 output (i.e., each instruction is assigned an IG). As noted, the instructions to instruction group mapping of circuit 473 may be modified according to the intended use of the software (e.g., the OS may want to group instructions by ISA version for compatibility, etc.). In some cases, the instruction groups may vary in granularity, and thus there may be a number of groups ranging from 2 (e.g., memory instructions and non-memory instructions) to the number of instructions in the ISA (e.g., each instruction in the ISA is its own group).

[0076] An IG permission 490 may thus be generated from the instruction 471 and its VA 474. In some embodiments, the permission 490 is enforced at the decode stage prior to execution. Alternatively, a permission 490 indicating a no-execution condition may set a flag causing an exception that may be signaled at a subsequent stage.

[0077] Evaluation 470 can therefore be used to determine whether the instruction to be executed is part of a permissible IG. For example, a certain subset of instructions in the ISA may affect sensitive registers and should only be permitted to execute from certain code areas (such as the operating system kernel). Such instructions can be defined as belonging to the same IG, and the group can have its permissions disabled for all VA areas except for the privileged code area. Among other things, this method allows sensitive instructions to be restricted to be executed as part of the kernel and blocked from being executed in other code (e.g., user mode).

[0078] FIG. 4A to FIG. 4C The techniques disclosed in the disclosures may be used alone or in combination with one another. For example, IG permissions may be used together with PC-based memory permissions, branch permissions, and execution permissions as needed. This specific implementation may be used to prevent the execution of instructions that would be permitted by other disclosed techniques. In other words, even if instructions of a particular IG are present in a VA region that passes other permission checks, their execution may be blocked.

[0079] Execution Mode

[0080] The above about FIG. 4A to FIG. 4C The described techniques provide flexibility for setting permissions on a granular basis. As described, different code portions may be given different permissions with respect to the same memory location, and a single code portion may be given different permissions with respect to different memory locations. Further, by using IG-based permissions, different code portions may be prevented from executing different subsets of instructions. This approach provides a great degree of flexibility and avoids the need for overhead-intensive context switching in order to enforce different permissions.

[0081] By using different execution modes, additional degrees of flexibility can be introduced. Each mode can have its own set of permissions relative to other modes. This method allows, for example, code to have different memory permissions relative to the same set of memory locations when executed in different modes. Similarly, certain instruction groups in a portion of the code can have different execution permissions in different modes. In some specific implementations, such modes can be set by setting bits in a special register in a privileged mode. In other cases, a special dedicated mode change instruction can be used to change the mode. As will be described below, in some embodiments, modes can be implemented by using different lookup tables, one lookup table corresponding to each possible mode and each implemented permission. For example, if execution permissions, memory permissions, and IG permissions are all implemented and there are three possible modes, then in a specific implementation, nine lookup tables can be used.

[0082] Figure 5A 504A) for a memory access instruction 502 having a PC 501 executed in one particular mode 503 among multiple possible modes. The instruction 502 includes an opcode 502A and operands 502B through 502C. The permission evaluation 500 is similar to Figure 4A 4. However, there are multiple possible LUTs for memory permissions 520B.

[0083] Execution permission 520A for instruction 502 is associated with Figure 4A 504B). As with memory permission 420B, memory permission 520B is determined using information from both the PC (VA 504A) and the target memory location (VA 504B) of the target instruction 502. First, PT 28 is accessed using source VA 504A to obtain primary index 506A and secondary index 508A. Then, PT 28 is accessed using target VA 504B and primary index 506B and secondary index 508B are obtained. LUT 510 is accessed using primary index 506B, thereby generating primary memory permission 516. However, with respect to secondary memory permission, mode value 503 is used to select one of LUTs 512, each of which may have a different permission value. Once a particular LUT 512 is selected, mask 518 is obtained using secondary indexes 508A and 508B. Primary permission 516 and mask 518 may then be combined (e.g., ANDed) in operation 519 to output memory access permission 520B. Thus, memory access permissions 520B may be selected based on three dimensions or properties—code location, memory location, and mode.

[0084] Note that mode 503 can also be used to modify other types of permissions already described. For example, Figure 4B An alternative embodiment of can support the mode for branch instructions by replacing LUT 412 with multiple LUTs and using mode 503 to select the appropriate mode. Similarly, Figure 4C Alternative embodiments may include multiple LUTs defining different IG permissions, where the appropriate LUT is selected based on mode 503.

[0085] Figure 5B is a block diagram of one embodiment of a permissions evaluation 550 for instructions executed in mode 503 . Figure 5B The general process described in Figure 4B The general flow depicted in is the same as in , but multiple LUTs are used to implement different permissions for different modes. As shown, the mode-specific LUT is selected for both instruction 432 (having PC2 431, opcode 432A, and operand 432B, operand 432B having target VA 544A) and 442 (having PC2 441 (which has VA 544A), opcode 442A, and operands 442B and 442C, operand 442C having target VA 544B).

[0086] Figure 5B An assessment of 550 with Figure 4B The main differences between evaluation 430 of , which depicts the permissive evaluation for a branch instruction without regard to mode, are the replacement of LUT 412 with LUT 512 and the use of mode 503 .

[0087] Branch permission 550A is determined using information from both instructions 432 and 442. Primary memory permission 556A is determined from LUT 510 based on primary index 546A obtained from page table 28 using VA 544A (the PC of instruction 442). At the same time, memory permission mask 558A is determined from LUT 512 (selected by mode 503) using secondary indexes 548A and 538. Secondary index 548A is obtained from PT 28 using VA 544A. Similarly, secondary index 538 is obtained from PT 28 using VA 534A (corresponding to the PC of instruction 432). Primary permission 556A and mask 558A are then combined in operation 559A to output branch permission 550A. Thus, information from both branch instruction 432 and target instruction 442 is used to verify that the branch is permitted.

[0088] Note that it can also be similar to the above Figure 4A The described manner of determining the execution permission 420A uses the primary index 546A to determine the execution permission 550B for the instruction 442 from the LUT 510 .

[0089] Similar to Figure 4A Memory access permissions 550C for instruction 442 are determined in the manner described for permissions 420B in operation 509. Specifically, permissions 550C are determined using information derived from both VA 544A (the PC of instruction 442) and VA 544B (the memory location addressed by instruction 442). Primary memory permissions 556B are determined from LUT 510 based on primary index 546B obtained from page table 28 using VA 544B (the PC of the target of instruction 442). Simultaneously, memory permission mask 558B is determined from LUT 512 selected by mode 503 using secondary indexes 548A-548B. Note that secondary index 548A may have been retrieved from PT 28 in the context of determining memory permissions 550A. Secondary index 548B is obtained from PT 28 using VA 544B. Primary permissions 556B and mask 558B are then combined in operation 559B to output memory access permissions 550C.

[0090] Exemplary Hardware Implementation

[0091] Various types of licenses have been described with respect to FIGS. 4-5. Although these licenses are shown separately in some cases, they may also be combined in various embodiments. FIG. 6A to FIG. 6C One possible hardware implementation combining the features of Figures 4-5 is described.

[0092] Fig. 6A 6 is a block diagram of permission evaluation circuit 600. Circuit 600 evaluates permissions for various types of instructions (e.g., branches, memory accesses, mode changes) using virtual addresses and lookup tables that retrieve IG permissions 665 and 628 according to various combinations of modes, instruction groups, and VA regions. As shown, circuit 600 includes page table 610, LUTs 620 and 650 and 660, mode management circuit 630, instruction region table circuit 640, and operation circuit 670. In some embodiments, circuit 600 is implemented within control circuit 24.

[0093] The page table 610 is configured to store a primary index and a secondary index for each VA region. As shown, the VA 604 of the instruction is used to access the table 610 and output a primary index 615A and a secondary index 615B, both of which are used to evaluate the license. The primary index 615A is used to obtain the primary license 628, while the secondary index 615B is used together with other data to obtain the secondary license 655.

[0094] Circuit 600 may be used to calculate permissions for different types of virtual addresses. Thus, in one use of circuit 600, VA 604 may be the PC of the instruction to be executed. In another use of circuit 600, VA 604 may be the memory address of a memory location being addressed by a memory access instruction.

[0095] LUT1 620 is configured to store primary licenses indexed by primary indexes. As shown, LUT1 620 is accessed using primary index 615A, thereby generating primary license 628. In some embodiments, LUT1 may be implemented using content addressable memory. In some embodiments, LUT1 620 may be implemented as a circuit that uses an indirect method to retrieve a license using index 615A, such as referring to FIG. Figure 6B Described in more detail.

[0096] FIG. 5A to FIG. 5B The use of LUT 512 to store permission information for different execution modes is described. LUT 512 is described as being accessed using three inputs: mode 503, secondary index 508A (obtained using the instruction PC), and secondary index 508B (obtained using the target address). Fig. 6A In the context of , the functionality of LUT 512 is implemented by the combination of instruction region table 640 and LUT2 650. It can be seen that instruction region table 640 receives previous secondary index 615O and previous pattern 635O, while LUT2 650 receives secondary index 615B. As will be described below, secondary index 615O can be considered equivalent to secondary index 508A, while secondary index 615B can be considered equivalent to secondary index 508B.

[0097] During a given instruction cycle, two versions of the secondary index 615B are available for use within the circuit 600. The current version of the index 615B may be used as an input to the LUT2 650. Additionally, the previous version of the secondary index 615O may be used as an input to the instruction region table 640. In this way, information from a previous instruction or stage is captured via the previous secondary index 615O and may be used when evaluating a permit to compare with data from a previous instruction or pipeline stage. Figure 4B In the example of , index 615O may correspond to secondary index 438 (obtained from VA 434 of instruction 432 ), while 615B may correspond to secondary index 448A (obtained from target PC VA 444A of instruction 441 ).

[0098] Secondary indexes 615B and 615O may be continuously updated. For example, in the context of FIG. 5 , at the fetch stage of branch target instruction 442, secondary index 615B corresponds to the index obtained from VA 544A of instruction 442. On the other hand, previous index 615O corresponds to the index obtained from branch instruction 432 located at VA 534. Then, at the decode / execute stage of instruction 442, secondary index 615B will be changed to the index obtained using the target address with VA 544B, while previous index 615O will be changed to the index previously in 615B (i.e., the index obtained from VA 544A of instruction 442), which is achieved by means of storage in register 614. Thus, circuit 600 is able to use information related to the previous processor state to evaluate permissions for both memory instructions and branch instructions.

[0099] In one embodiment, instruction region table circuit 640 is a table that can receive information from secondary index 615O and previous mode 635O and output source index 645, which can be smaller in size than the concatenation length of 615O and 635O. In one specific implementation, 615O and 635O can each be 7 bits, and source index 645 is 7 bits, representing a compressed version of the combination of 615O and 635O. Therefore, source index 645 can capture information about the previous pipeline stage, which is different from secondary index 615B related to the current pipeline stage. The combination of source index 645 and secondary index 615B can be concatenated to act as an index into LUT2 650. Note that source index 645 is also provided as input to mode management circuit 630 and IG LUT 660.

[0100] LUT2 650 is configured to store and output a secondary permission 655 indexed by a secondary index 615B (obtained from PT 610) and a source index 645 (obtained from instruction region table circuit 640). Source index 645 corresponds to data from a previous instruction, while secondary index 615B corresponds to the current instruction. In a sense, secondary permission 655 can be thought of as describing whether it is permitted to "go from" a previous instruction to the current instruction.

[0101] Primary permission 628 and secondary permission 655 are combined at circuit 670 to output permission 675. Permission 675 may correspond to fetch permission 675A when determined at the fetch stage. These permissions are typically associated with instructions (e.g., branches). On the other hand, read / write permission 675B is typically associated with memory. In some embodiments, circuit 670 may output a separate permission bit depending on the stage of the instruction. However, in other embodiments, circuit 670 is configured to update a four-bit permission register once at the beginning of an instruction cycle, which is then accessed by the processor at the appropriate stage.

[0102] Because changes in mode can significantly affect permissions (allowing instructions to access data they are not authorized to access), steps can be taken to prevent unauthorized mode changes. Therefore, the mode management circuit 630 is configured to output the update mode 637 in the current cycle and ensure that unauthorized mode change instructions are not executed. Most instructions do not change the update mode 637, and the update mode 637 and the previous mode 6350 therefore typically have the same value. However, for mode change instructions, the circuit 630 uses the index 645 corresponding to the instruction to determine whether the value of the update mode 637 will change. Figure 6C One embodiment of circuit 630 is described in more detail. Note that the other elements of circuit 600 only "see" the previous mode 635O, which prevents the evaluation of permissions based on unauthorized new modes. Once the new mode is approved, it will become the previous mode 635O in the next cycle and will therefore be visible to the rest of circuit 600.

[0103] IG LUT 660 is configured to store IG permissions 665, which act as an additional "overlay" to execution permissions 675A. Some or all of index 645 may identify an instruction group of instructions. It is worth noting that an entity may modify the value of LUT 660 to enforce execution policy on permissions of a certain group (as opposed to modifying instructions according to their VA). In some embodiments, LUT 660 may be additionally indexed by mode to achieve further granularity. For example, a processor may disable some high power consumption instructions in a given execution mode to increase battery life. In other embodiments, IG LUT 660 is not used, and processor 10 only uses permissions 675.

[0104] Thus, circuit 600 uses multiple criteria to determine whether a program is permitted to execute. It is noteworthy that due to the use of registers that store previous stage information via instruction region table 640 and mode management circuit 630 that determines whether the mode can be changed, circuit 600 of this embodiment supports branch instructions, memory access instructions, and mode change instructions. Circuit 600 can be implemented as a single circuit of processor 10, or the functionality of the circuit can be split across multiple circuits. For example, the LUT can be stored in memory, and other circuit systems can be part of processor 10.

[0105] Figure 6B 6 is a block diagram of one embodiment of a LUT1 620 configured to evaluate a primary license 628 based on a primary index 615A. As shown, LUT1 620 includes a base address register 621, an overlay register 623, and an operation circuit 625. As further shown, the lookup of LUT1 620 is split into two parallel lookups rather than a single lookup. Fig. 6A A single lookup is depicted.

[0106] In the illustrated embodiment, LUT1 620 is configured to split primary index 615A into fields 616A to 616B. Field 616A is used to retrieve base license 622 from base register 621, and field 616B is used to retrieve overlay license 624 from overlay register 623. Finally, base license 622 and overlay license 624 are combined (e.g., ANDed) at operation circuit 625 to output primary license 628.

[0107] It is noteworthy that each field 616A and 616B includes different bits of the primary index 615A. This approach can allow permissions 628 to be more granular relative to a single index 615A because registers 621 and 623 can be changed independently. For example, a base register 621 that can correspond to different PC regions can be set independently of different overlay registers 623 that can correspond to different memory locations being accessed. As another advantage, registers 621 and 623 can have lower read / write latency than data stored in memory 30, thereby allowing permission modifications to be completed more quickly.

[0108] Alternative embodiments of LUT1 620 are also contemplated, including those that may use additional input types and / or indexes. For example, LUT1 620 may be further configured to use mode information and thus include additional base registers 621 and / or overlay registers 623 selected according to the appropriate mode. As another example, overlay register 623 may be indexed by the instruction group of replacement field 616B, so that permission 628 also considers the instruction group of the instruction.

[0109] Figure 6C 636. is an exemplary embodiment of a mode management circuit 630 configured to evaluate an update mode 637. When the current instruction is not a mode change instruction, the value of the update mode 637 (and therefore the previous mode 6350) is not changed. However, when the current instruction is a mode change instruction to set a new mode 636, the circuit 630 is configured to determine whether the mode is permitted to change. This check is performed using the mode transition table 632 before updating the value of the mode 637.

[0110] Mode transition table 632 is configured to store mode transition permissions indexed by previous mode 6350 and source index 645. For example, table 632 may be configured to allow transition from a mode associated with kernel code to a mode associated with OS code, and not to allow transition in the reverse direction. It should be noted that the association between mode and code may be determined by processor 10, and therefore updated according to program and processor requirements. For example, a more complex processor may use more modes (and therefore result in a larger table 632) than a less complex processor. In some embodiments, new mode 636 may be obtained using the selected bit of source index 645, and used together with previous mode 635 to determine whether to allow a change from mode 6350 to new mode 636. If mode change is permitted, multiplexer selects new mode 636 to update mode register 634 to update mode 637. In the illustrated embodiment, the value of mode 6350 (due to register 634) will change in subsequent clock cycles after the value of the mode 637 is updated. On the other hand, if the change is not permitted according to table 632, an exception may be signaled, the mode change instruction may be aborted, and / or the update mode 637 may retain the value of the previous mode 6350. Like other tables, table 632 may be indexed using different types of indexes. For example, table 632 may be indexed by two secondary indexes similar to LUT 412.

[0111] Fig. 7A 705 is an example of memory permissions within the VA space 700 of the same process 705. As shown, the VA space 700 includes code A at VA region 710, data A at VA region 720, and code B at VA region 730. Arrows from one VA region to another VA region indicate the desired permissions to be enforced. The arrow from code A to data A indicates that code A has read / write access to data, while the dashed arrow from code B to data A indicates that code B should not be able to access data A. Table 1 shown below summarizes the desired permissions.

[0112] source destination operate allow? Code A Data A Read yes Code B Data A Read no

[0113] Table 1

[0114] According to some embodiments, these permissions may be stored in a permission table and retrieved using the source VA and destination VA. In this specific example, processor 10 may use VA regions 710 and 720 to obtain (via, for example, page table 20) an index used in a permission table (e.g., LUT 412) and then determine that code A is permitted to read data A. Similarly, processor 10 may use VA regions 720 and 730 in a similar manner to determine that code B is not permitted to read data A.

[0115] These permissions can be used to "sandbox" different parts of a process as needed to isolate them from each other. For example, the disclosed technology can be used to enable a "malloc" routine of a process (e.g., code A) to maintain and access malloc metadata (e.g., data structures such as found in data A) while preventing other routines of the process (e.g., code B) from accessing the metadata. As another example, the kernel can maintain metadata and simultaneously allow kernel code to access the metadata while denying untrusted third-party driver code that access. Implementing these "policies" can be achieved by modifying the permission table permissions so that the table will include appropriate permissions at corresponding virtual address sets.

[0116] Figure 7B 755A and 755B. As shown, VA space 750 includes code A and data A at VA regions 775 and 780, respectively, code B and data B at VA regions 760 and 765, respectively, and shared library code at VA region 770. It is worth noting that code A and data A belong to process 755A, code B and data B belong to process 755B, and shared library code is used by both processes 755A to 755B.

[0117] Figure 7B It is shown that the access permissions change according to different modes. As shown, in mode 0, the execution instruction evaluates that the shared library code has read / write permissions for data A of process 755A and execute permissions for code A, but does not have permissions for code B or data B of process 755B. In contrast, in mode 1, the execution instruction evaluates that the shared library code has permissions for code B and data B of process 755B, but does not have permissions for code A and data A of process 755A.

[0118] This method allows, for example, to protect the data and code of one process from being accessed by another process via shared library code. For example, if code A of process 755A (executed in mode 0) will execute shared library code to access data B of process 755B, the processor will block access to data B because the shared library code does not have permission to the data in mode 0. It should be noted that further security measures can be implemented to prevent unauthorized mode changes that will circumvent these permissions. For example, the value of mode transition table 632 (not shown) can be modified to prevent code A and shared library code from changing mode from mode 0 to mode 1 to access data B, and conversely, to prevent code B and shared library code from changing mode from mode 1 to mode 0 to access access A. In some embodiments, the evaluation of these permissions is performed by processor 10 using the mode, source VA, and destination VA of each instruction using one or more permission tables (e.g., LUT 520).

[0119] Exemplary Methods

[0120] Fig. 8A 800 is a flowchart illustrating one embodiment of the operation of processor 10 for a memory access instruction, labeled method 800. However, the blocks are shown in a particular order for ease of understanding, and other orders may be used. The blocks may be executed in parallel in the combinatorial logic circuitry of processor 10. The blocks, combinations of blocks, and / or the flowchart as a whole may be pipelined over multiple clock cycles. Processor 10 and / or portions thereof may be configured to implement Fig. 8A The illustrated operation.

[0121] The processor 10 may obtain a primary permission table index from the page table entry of the memory address being accessed (block 805). The primary permission table index may be obtained indirectly if the memory address hits in the TLB 26, or may be read directly in a table walk if the memory address does not hit in the TLB 26. The processor 10 may obtain a secondary permission index from the page table entry of the PC (directly or indirectly from the TLB 26) (block 810). Note that in some embodiments, the secondary permission index may be obtained when the instruction is fetched, while the primary permission table index may be obtained during instruction execution.

[0122] The processor 10 may combine the primary permission and the secondary permission index to generate a combined permission table index (block 815). The processor 10 may obtain the memory access permission from the permission table 20 based on the combined permission table index (block 820). The processor 10 may execute the memory access instruction based on the memory access permission provided from the permission table 20 (block 825).

[0123] Figure 8B 8 is a flow chart of one embodiment of a method 840 for providing instruction memory access permissions. In one embodiment, the method 840 is performed by a processor such as the processor 10. The method 840 may be performed to provide memory permissions for a variety of instruction types, including control flow instructions (e.g., instructions 432) and memory access instructions (e.g., instructions 442).

[0124] Method 840 begins at step 845, where a processor (e.g., processor 10) of a computer system (e.g., system 100) receives a specific instruction to be executed by an execution pipeline of the processor (e.g., execution core 12), the specific instruction including a reference to a first memory address and located at a second memory address.

[0125] Method 840 continues at step 850, where the processor stores the plurality of permissions for access to the memory in a permission table (e.g., permission table 20), where the permission table circuit is indexed by a particular permission table index (e.g., PTI 38). In some embodiments, the permission table may define two or more different memory permissions for accessing a particular memory location from different code locations.

[0126] Next, in step 855, the processor generates a specific permission table index for the specific instruction based on 1) a first value corresponding to a first memory address indicated by the specific instruction and 2) a second value corresponding to a second memory address where the specific instruction is stored.

[0127] The first value and the second value may be stored in one or more permission tables. In some cases, the first value is stored in the page table in association with a first physical page number to which the first memory address is converted, and the second value is stored in the page table in association with a second physical page number to which the second memory address is converted. The first value and the second value may additionally or alternatively be cached in one or more additional elements: In some embodiments, the first value and the second value are stored in a TLB coupled to the processor.

[0128] In some embodiments, the processor generates a specific permission table index by concatenating a first value and a second value. The permission table index can be a secondary index used by the processor to access a specific permission set from the permission table. In addition, the processor can also generate a primary index for a specific instruction based on a third value corresponding to the first memory address, retrieve a base memory permission set from the permission table circuit using the primary index and retrieve a permission mask from the permission table circuit using the secondary index, and combine the base memory permission set and the permission mask to obtain a final memory permission set for the instruction.

[0129] In some embodiments, the particular instruction is a control flow instruction and the second memory address is a target of the control flow instruction. In such cases, in response to the target of the control flow instruction being a load-store instruction, the processor may generate a different permission table index for the target of the control flow instruction based on a third value corresponding to a third memory address accessed by the target of the control flow instruction and a fourth value corresponding to a fourth memory address at which the target of the control flow instruction is stored.

[0130] Next, in step 860, the processor retrieves a specific permission for the specific instruction from among the plurality of permissions using the specific permission table index (eg, via page table 28).

[0131] In some embodiments, the retrieval may include selecting a permission table from a set of permission tables based on a current execution mode of the processor, and accessing the selected permission table using a specific permission table index to retrieve a specific permission. The execution mode and the specific permission table index may be from a previous clock cycle of the processor. When a mode is used, the processor may also include a mode checking circuit configured to determine whether a mode change specified by an instruction is permitted before propagating the new mode value throughout the execution pipeline.

[0132] The processor may use an additional table to retrieve more permissions. For example, in some embodiments, the processor further uses a secondary execution privilege table circuit that stores multiple secondary execution privilege values. In this case, the secondary execution privilege table is indexed by a specific secondary execution privilege index corresponding to a specific instruction to provide a specific secondary execution privilege value for a specific instruction, and the specific secondary execution privilege value defines a permissible set of multiple instruction groups that can be executed from a second memory address, and the processor is configured to selectively allow the computer processor to execute a specific instruction when the specific instruction is in a permissible set of multiple instruction groups defined by the secondary execution privilege value. In addition, the specific secondary execution privilege index may be associated with a specific page table entry mapped to the second memory address, and the control circuit is further configured to selectively allow the computer processor to execute a specific instruction based on the primary execution privilege associated with the specific page table entry. In some embodiments, the processor uses multiple permission tables that specify different permissions for a specific instruction. Then, the processor can obtain a permission for a specific instruction in the following manner: select a permission table from a plurality of permission tables based on the execution mode of the computer processor, and retrieve the permission for a specific instruction from the selected permission table using a specific permission table index.

[0133] Next, in step 865, the processor enforces the final memory permissions based on the specific permissions during execution of the specific instructions.

[0134] Additionally, in some embodiments, the specific permission is a permission mask, and the processor may further determine the base memory permission from a permission table lookup based on a third value corresponding to the first memory address, and generate a final permission from the base memory permission and the specific permission. The processor may also determine execution permissions for the specific instruction from a permission table lookup based on a fourth value corresponding to the second memory address. Additionally or alternatively, the processor may determine secondary execution privileges for the specific instruction from a permission table lookup based on a fifth value corresponding to the second memory address, the secondary execution privileges defining which of a plurality of permission groups are permitted to be executed from the second memory address.

[0135] Now turn to Fig.9A, a flowchart (labeled method 900) illustrating one embodiment of operations executed by instructions of processor 10 is shown. However, for ease of understanding, the blocks are shown in a particular order, and other orders may also be used. The blocks may be executed in parallel in the combinatorial logic circuitry of processor 10. The blocks, combinations of blocks, and / or the flowchart as a whole may be pipelined over multiple clock cycles. Processor 10 and / or portions thereof may be configured to implement Fig.9A The operation illustrated.

[0136] The processor 10 may obtain the permission index and the secondary execution privilege value from the page table entry of the PC (directly or indirectly through the TLB 26) (block 905). In another embodiment, the page table entry / TLB of the PC may include a secondary execution privilege table index, and the processor 10 may use the secondary execution privilege table index to obtain the secondary execution privilege value. The processor 10 may determine whether the processor 10 is privileged to execute the instruction (decision block 910). For example, if the permission includes execution permission and the secondary execution privilege indicates execution permission for the instruction group (if any), the processor 10 may be privileged to execute the instruction (the "yes" branch of decision block 910, and block 915). If the permission does not include execution permission and / or the secondary execution privilege does not indicate execution permission for the instruction group (if any), the processor 10 may prevent the instruction from executing (e.g., signaling an exception instead of executing the instruction) (the "no" branch of decision block 910, and block 920).

[0137] In another embodiment, the actual permission (AP) may be determined in any of the following ways: Given PC1, PC2 (PC primary and secondary indices) and T1, T2 (target primary and secondary indices), there are various methods for determining the actual permission (AP), such as (where # is concatenation and & is a bitwise AND operation):

[0138] AP=LUT2(T1#PC2)

[0139] AP=LUT1(T1)&LUT2(T1#PC2)

[0140] AP=LUT1(T1)&LUT2(T2#PC2)

[0141] Where LUT1 (T1) is looking for the primary license which is modified (bitwise ANDed) by LUT2.

[0142] Fig. 9Bis a flow chart of one embodiment of a method 940 for providing instruction memory access permissions. In one embodiment, the method 940 is performed by a processor such as the processor 10. The method 940 may be performed to provide memory permissions for a variety of instruction types, including control flow instructions (e.g., instructions 431) and memory access instructions (e.g., instructions 441).

[0143] Method 940 begins at step 945, where a processor (eg, processor 10) of a computer system (eg, system 100) receives a specific instruction of an instruction set architecture (ISA) of the processor, the specific instruction being located at a first memory address of a memory of the computer system.

[0144] Method 940 continues at step 950, where the processor stores a plurality of secondary execution privileges in a permission table (e.g., permission table 20) that define, for instructions stored at different memory locations, which of a plurality of instruction groups of the ISA are executable from those memory locations.

[0145] Next, in step 955, the processor generates a specific secondary execution privilege index for the specific instruction. In some embodiments, the specific secondary execution privilege index is associated with the page table entry to which the first memory address is mapped. The processor can further selectively permit execution of the specific instruction based on the primary execution privilege associated with the page table entry.

[0146] Method 940 continues at step 960, where the processor retrieves a specific secondary execution privilege value corresponding to the first memory address using the specific secondary execution privilege index (e.g., via page table 28). In some embodiments, the specific secondary execution privilege value is stored in a specific permission table of a plurality of permission tables, and the processor may select the specific permission table based on an execution mode of the processor. In addition, the control circuitry may include a mode checking circuit configured to determine whether a mode change instruction is authorized before changing the execution mode of the processor.

[0147] Next, in step 965, the processor determines whether to permit execution of the specific instruction based on the specific secondary execution privilege value and the specific instruction. In some embodiments, the processor may permit execution of the specific instruction based on the specific secondary execution privilege value indicating execution privilege for a given instruction group, but may prevent execution of the specific instruction based on the specific secondary execution privilege value not indicating execution privilege for the specific instruction group. The processor may further cause a signaling exception in response to the specific secondary execution privilege value not indicating execution privilege for the specific instruction group.

[0148] In some embodiments, the determination is also based on the primary execution permissions obtained by indexing into the lookup table using the primary index, the primary index being obtained using the first memory address. For example, the primary execution permissions may indicate whether any code is permitted to execute at the first memory address, and the specific secondary execution privilege value may indicate which instruction groups of the ISA are permitted to execute at the first memory address. The determination may therefore include satisfying both the primary execution permissions and the specific secondary execution privilege value.

[0149] Method 940 may include more steps than shown. For example, the method may also include modifying, by the processor, the permission table to change which instruction groups of the plurality of instruction groups are executable from the first memory address.

[0150] Method 940 may include additional permission types. For example, the processor may further enforce memory permissions in response to a particular instruction being a memory access instruction indicated as executable by a particular secondary execution privilege value. The control may use a memory permission index to obtain the memory permission, the memory permission index being generated based on the first memory address and a target memory address specified by the memory access instruction.

[0151] The following numbered clauses list various non-limiting embodiments disclosed herein:

[0152] Set A A1. A device, the device comprising:

[0153] A processor, the processor comprising:

[0154] a grant table circuit configured to store a plurality of permissions for access to memory, wherein the grant table circuit is indexed by a specific permission table index corresponding to a specific instruction to provide specific permissions for a specific memory access by the specific instruction; and

[0155] A control circuit coupled to the grant table circuit and configured to generate the particular grant table index based on:

[0156] a first value corresponding to a first memory address indicated by the particular instruction; and

[0157] A second value corresponding to the second memory address at which the particular instruction is stored.

[0158] A2. An apparatus according to any of the preceding clauses within set A, further comprising: a translation lookaside buffer (TLB) coupled to the control circuit, wherein the TLB is configured to store one or more of the first value and the second value.

[0159] A3. An apparatus according to any of the preceding clauses within set A, wherein the first value is stored in a page table in association with a first physical page number to which the first memory address is converted, and wherein the second value is stored in the page table in association with a second physical page number to which the second memory address is converted.

[0160] A4. An apparatus as described in any preceding clause within set A, wherein the control circuit is configured to generate the particular permissions table index by cascading the first value and the second value.

[0161] A5. An apparatus according to any preceding clause within set A, wherein the particular permissions table index is a secondary index, and wherein the control circuit is configured to access a particular permissions set from the permissions table circuit using the secondary index, wherein the particular permissions set is a permissions mask;

[0162] wherein the control circuit is configured to generate a primary index of the specific instruction based on a third value corresponding to the first memory address; and

[0163] wherein the control circuitry is configured to retrieve the base memory permissions set from the grant table circuitry using the primary index and to retrieve the permissions mask from the grant table circuitry using the secondary index; and

[0164] The control circuit is configured to combine the base memory permission set and the permission mask to obtain a final memory permission set for the specific instruction.

[0165] A6. An apparatus according to any preceding clause within set A, wherein the particular instruction is a control flow instruction, wherein the first memory address is a target of the control flow instruction.

[0166] A7. An apparatus according to clause A6, wherein in response to the target of the control flow instruction being a load-store instruction, the control circuitry is configured to generate a different permission table index for the target of the control flow instruction based on:

[0167] a third value corresponding to a third memory address accessed by the target of the control flow instruction; and

[0168] A fourth value corresponding to a fourth memory address at which the target of the control flow instruction is stored.

[0169] A8. An apparatus according to any of the preceding clauses in Set A, further comprising:

[0170] A secondary execution privilege table circuit is configured to store a plurality of secondary execution privilege values, wherein:

[0171] The secondary execution privilege table circuit is indexed by the specific secondary execution privilege index corresponding to the specific instruction to provide the specific secondary execution privilege value for the specific instruction;

[0172] The particular secondary execution privilege value defines a permissible set of a plurality of instruction groups that can be executed from the second memory address; and

[0173] The control circuitry is configured to selectively permit the processor to execute the particular instruction when the particular instruction is in the permissible set of the plurality of instruction groups defined by the particular secondary execution privilege value.

[0174] A9. An apparatus according to clause A8, wherein the particular secondary execution privilege index is associated with a particular page table entry to which the second memory address is mapped; and

[0175] Wherein the control circuit is further configured to selectively permit the processor to execute the particular instruction based on a primary execution privilege associated with the particular page table entry.

[0176] A10. An apparatus according to any preceding clause in set A, wherein the permission table circuit is configured to store a plurality of permission tables specifying different permissions for the particular instruction;

[0177] The control circuit is configured to obtain permission for the specific instruction in the following manner:

[0178] selecting a permission table from the plurality of permission tables based on an execution mode of the processor; and

[0179] The permission for the particular instruction is retrieved from the selected permission table using the particular permission table index.

[0180] A11. A method, comprising:

[0181] receiving, in a processor of a computer system, a specific instruction to be executed by an execution pipeline circuit of the processor, the specific instruction including a reference to a first memory address and located at a second memory address;

[0182] storing, by the processor, a plurality of permissions for access to a memory of the computer system in a permissions table, wherein the permissions table is indexed by a permissions table index; and

[0183] The specific grant table index for this specific instruction is generated by the processor based on:

[0184] a first value corresponding to the first memory address; and

[0185] a second value corresponding to the second memory address;

[0186] Retrieving, by the processor, a specific permission for the specific instruction from the permission table using the specific permission table index; and

[0187] Final memory permissions based on the particular permissions are enforced by the processor during execution of the particular instruction.

[0188] A12. The method of clause A11, wherein the particular permission is a permission mask, the method further comprising:

[0189] determining base memory permissions from a permissions table lookup based on a third value corresponding to the first memory address; and

[0190] The final storage license is generated from the base storage license and the specific license.

[0191] A13. A method according to any one of clauses A11 to A12, further comprising:

[0192] Execution permissions for the particular instruction are determined from a permissions table lookup based on a fourth value corresponding to the second memory address.

[0193] A14. A method according to any one of clauses A11 to A13, further comprising:

[0194] A secondary execution privilege for the particular instruction is determined from a permission table lookup based on a fifth value corresponding to the second memory address, the secondary execution privilege defining which permission groups of the plurality of permission groups are permitted to execute from the second memory address.

[0195] A15. A method according to any one of clauses A11 to A14, further comprising:

[0196] The grant table is selected from a set of grant tables based on a current execution mode of the processor.

[0197] A16. A method as described in any of clauses A11 to A15, wherein the permission table defines two or more different memory permissions for accessing a particular memory location from different code locations.

[0198] A17. A device, comprising:

[0199] A processor configured to execute computer program instructions, the processor comprising:

[0200] a grant table circuit configured to store a plurality of permissions for access to the memory in a set of permission tables, wherein the set of permission tables is indexed by a permission table index;

[0201] An execution pipeline circuit is configured to receive a specific instruction for execution, the specific instruction specifies a first memory address to be accessed by the specific instruction, and the specific instruction is located at a second memory address, wherein a control circuit of the execution pipeline circuit is configured to:

[0202] generating a specific permission table index for the specific instruction based on the first memory address and the second memory address;

[0203] retrieving from the grant table circuitry a specific permission for the specific instruction from the plurality of permissions using the specific permission table index, the specific permission being specific to code executing at the second memory address and accessing a memory location at the first memory address; and

[0204] Final memory permissions based on the particular permissions are enforced during execution of the particular instruction.

[0205] A18. An apparatus according to clause A17, wherein the execution pipeline is configured to retrieve the specific permission by:

[0206] selecting a grant table from the grant table circuitry of a plurality of grant tables based on an execution mode of the processor; and

[0207] The selected permission table is accessed using the specific permission table index to retrieve the specific permission.

[0208] A19. An apparatus as described in clause A18, wherein the execution mode and the particular permission table index are from a previous clock cycle of the processor.

[0209] A20. An apparatus as described in clause A18 or A19, wherein the control circuit includes a mode checking circuit configured to determine whether a mode change specified by an instruction is permitted before propagating a new mode value throughout the execution pipeline circuit.

[0210] A21. An apparatus for performing a method according to any of clauses A11 to A16.

[0211] A22. A non-transitory computer-readable storage medium having stored thereon instructions in a hardware description language, wherein the instructions are executable by a computing system to program the computing system to generate a computer simulation model, wherein the computer simulation model represents a hardware circuit including any of the devices described in set A.

[0212] Set B

[0213] B1. A device comprising:

[0214] A processor, the processor comprising:

[0215] a permission table circuit configured to store a plurality of secondary execution privileges, wherein the permission table circuit is indexed by a specific secondary execution privilege index corresponding to a specific instruction to provide a specific secondary execution privilege value for the specific instruction, the specific secondary execution privilege value defining which instruction groups of a plurality of instruction groups of an instruction set architecture (ISA) of the processor are executable from a first memory address at which the specific instruction is stored; and

[0216] A control circuit is coupled to the permission table circuit and is configured to selectively permit the processor to execute the specific instruction when the specific instruction is in a specific instruction group indicated as executable by the specific secondary execution privilege value.

[0217] B2. An apparatus according to any of the preceding clauses within set B, wherein the control circuit is configured to permit the processor to execute the specific instruction based on the specific secondary execution privilege value indicating execution privilege for the specific instruction group, and wherein the control circuit is configured to prevent the processor from executing the specific instruction based on the specific secondary execution privilege value not indicating execution privilege for the specific instruction group.

[0218] B3. An apparatus as described in any preceding clause within set B, wherein the control circuitry is configured to cause a signaling exception in response to the particular secondary execution privilege value not indicating execution privileges for the particular instruction.

[0219] B4. An apparatus as described in any preceding clause within set B, wherein the particular secondary execution privilege index is associated with a page table entry to which the first memory address is mapped.

[0220] B5. An apparatus as described in clause B4, wherein the control circuit is further configured to selectively permit the processor to execute the particular instruction based on the primary execution privilege associated with the page table entry.

[0221] B6. An apparatus as described in any of the preceding clauses within set B, wherein the control circuitry is further configured to enforce memory permission in response to the particular instruction being a memory access instruction indicated as executable by the particular secondary execution privilege value, wherein the control circuitry is configured to obtain the memory permission using a memory permission index generated based on the first memory address and a target memory address specified by the memory access instruction.

[0222] B7. An apparatus as described in any of the preceding clauses within set B, wherein the particular secondary execution privilege value is stored in a particular permission table among a plurality of permission tables, wherein the control circuit is configured to select the particular permission table based on an execution mode of the processor.

[0223] B8. An apparatus as described in clause B7, wherein the control circuit includes a mode checking circuit configured to determine whether a mode change instruction is authorized before changing the execution mode of the processor.

[0224] B9. An apparatus according to any of the preceding clauses within set B, wherein the control circuit is configured to determine that the specific instruction is in the specific instruction group indicated by the specific secondary execution privilege value based on the opcode of the specific instruction and a mapping of the opcode of the ISA to instruction groups.

[0225] B10. An apparatus according to any preceding clause within set B, wherein the control circuit is configured to write to the permission table circuit to change the set of instruction groups designated as executable at the first memory address.

[0226] B11. A method, comprising:

[0227] A processor of a computer system receives a specific instruction of an instruction set architecture (ISA) of the processor, the specific instruction being located in a first storage unit of a memory of the computer system.

[0228] Device address;

[0229] storing, by the processor, in a permission table, a plurality of secondary execution privileges, the plurality of secondary execution privileges defining, for instructions stored at different memory locations, which instruction groups of a plurality of instruction groups of the ISA are executable from those memory locations;

[0230] generating, by the processor, a specific secondary execution privilege index for the specific instruction based on a first value corresponding to the first memory address;

[0231] Retrieving, by the processor, a specific secondary execution privilege value corresponding to the first memory address from the permission table using the specific secondary execution privilege index; and

[0232] The processor determines whether to permit execution of the specific instruction based on the specific secondary execution privilege value and the specific instruction.

[0233] B12. A method according to clause B11, wherein the determination is also based on using the primary index to search

[0234] A primary execution permission is obtained by referencing a lookup table, the primary index being obtained using the first memory address.

[0235] B13. A method according to clause B12, wherein the primary execution permission indicates whether any code is permitted to execute at the first memory address, wherein the specific secondary execution privilege value indicates which instruction groups of the ISA are permitted to execute at the first memory address, and wherein the determination includes satisfying both the primary execution permission and the specific secondary execution privilege value.

[0236] B14. A method according to clauses B11 to B13, wherein the permission table is selected from a plurality of permission tables using an execution mode of the processor.

[0237] B15. A method according to any one of clauses A11 to A14, further comprising:

[0238] The permission table is modified by the processor to change which instruction groups of the plurality of instruction groups are executable from the first memory address.

[0239] B16. A device comprising:

[0240] A processor configured to:

[0241] receiving a specific instruction for execution at an execution pipeline, the specific instruction being located at a first virtual memory address;

[0242] accessing an entry of a page table using the first virtual memory address, the entry storing a physical page number to which the first virtual memory address is mapped and an indication of a particular secondary execution privilege value, the particular secondary execution privilege value specifying which instruction groups of a plurality of instruction groups of an instruction set architecture (ISA) of the processor are permitted to execute at the first virtual memory address; and

[0243] A determination is made whether execution of the particular instruction is permitted based on the particular secondary execution privilege value and a determination of which instruction group the particular instruction belongs to.

[0244] B17. An apparatus as described in clause B16, wherein the processor is further configured to determine whether to permit execution of the particular instruction using a primary execution privilege accessed from a lookup table using a primary index stored in the entry of the page table.

[0245] B18. An apparatus according to B16 or B17, wherein the indication of the particular secondary execution privilege value is a secondary index to a particular secondary execution privilege table in a plurality of secondary execution privilege tables, the particular secondary execution privilege table being selected by a mode value indicating an execution mode of the processor, the secondary index specifying a location in the particular secondary execution privilege table where the particular secondary execution privilege value is stored.

[0246] B19. An apparatus according to any of clauses B16 to B18, wherein the processor is configured to enforce memory permissions in response to the particular instruction being a memory access instruction by:

[0247] generating a memory permission index based on the first virtual memory address and a target virtual memory address specified by the particular instruction;

[0248] retrieving a memory grant value using the memory grant index; and

[0249] This memory permission value for this particular instruction is enforced.

[0250] B20. An apparatus according to any one of clauses B16 to B19, wherein the processor is configured to signal an exception rather than permit execution of the particular instruction based on determining from the particular secondary execution privilege value that the instruction group of the particular instruction is not permitted to be executed from the first virtual memory address.

[0251] B21. An apparatus for performing a method according to any one of clauses B11 to B15.

[0252] B22. A non-transitory computer-readable storage medium having stored thereon instructions in a hardware description language, wherein the instructions are executable by a computing system to program the computing system to generate a computer simulation model, wherein the computer simulation model represents a hardware circuit comprising any of the devices described in set B.

[0253] Exemplary Devices

[0254] Reference now Fig.10 , a block diagram of an exemplary embodiment of an exemplary device 1000 is shown. In some embodiments, the device 1000 may implement the functionality of the processor 10 and / or the circuit 600. In some embodiments, the elements of the device 1000 may be included in a system on a chip. In some embodiments, the device 1000 may be included in a mobile device that may be battery-powered. Therefore, the power consumption of the device 1000 may be an important design consideration. In the illustrated embodiment, the device 1000 includes a structure 1010, a computing complex 1020, an input / output (I / O) bridge 1050, a cache memory controller 1045, a graphics unit 1075, and a display unit 1065. In some embodiments, in addition to or in place of the illustrated components, the device 1000 may include other components (not shown), such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.

[0255] The structure 1010 may include various interconnects, buses, MUXs, controllers, etc., and may be configured to facilitate communication between various elements of the device 1000. In some embodiments, portions of the structure 1010 may be configured to implement a variety of different communication protocols. In other embodiments, the structure 1010 may implement a single communication protocol, and elements coupled to the structure 1010 may be internally converted from the single communication protocol to other communication protocols.

[0256] In the illustrated embodiment, computing complex 1020 includes bus interface unit (BIU) 1025, cache 1030, and cores 1035 and 1040. In various embodiments, computing complex 1020 may include various numbers of processors, processor cores, and caches. For example, computing complex 1020 may include 1, 2, or 4 or any other suitable number of processor cores. In one embodiment, cache 1030 is a group-associative L2 cache. In some embodiments, cores 1035 and 1040 may include internal instruction and data caches. In some embodiments, a consistency unit (not shown) in structure 1010, cache 1030, or elsewhere in device 1000 may be configured to maintain consistency between the various caches of device 1000. BIU 1025 may be configured to manage communications between computing complex 1020 and other elements of device 1000. Processor cores (such as cores 1035 and 1040) may be configured to execute instructions of a specific instruction set architecture (ISA) that may include operating system instructions and user application instructions. These instructions may be stored in a computer readable medium, such as a memory coupled to the memory controller 1045 discussed below.

[0257] As used herein, the term "coupled to" may indicate one or more connections between elements, and a coupling may include intermediate elements. Fig.10 In FIG. 1 , graphics unit 1075 may be described as being "coupled to" memory via structure 1010 and cache / memory controller 1045. In contrast, in Fig.10 In the illustrated embodiment, graphics unit 1075 is "directly coupled" to structure 1010 because there are no intervening elements.

[0258] The cache / memory controller 1045 may be configured to manage data transfers between the structure 1010 and one or more caches and memories. For example, the cache / memory controller 1045 may be coupled to an L3 cache, which in turn may be coupled to a system memory. In other embodiments, the cache / memory controller 1045 may be directly coupled to the memory. In some embodiments, the cache / memory controller 1045 may include one or more internal caches. The memory coupled to the controller 1045 may be any type of volatile memory, such as a dynamic random access memory (DRAM), a synchronous DRAM (SDRAM), a double data rate (DDR, DDR2, DDR3, etc.) SDRAM (including a mobile version of SDRAM, such as mDDR3, etc., and / or a low power version of SDRAM, such as LPDDR4, etc.), a RAMBUS DRAM (RDRAM), a static RAM (SRAM), etc. One or more memory devices may be coupled to a circuit board to form a memory module, such as a single inline memory module (SIMM), a dual inline memory module (DIMM), etc. Alternatively, these devices may be mounted with integrated circuits in a chip stack configuration, a package stack configuration, or a multi-chip module configuration. The memory coupled to the controller 1045 may be any type of non-volatile memory, such as NAND flash memory, NOR flash memory, nano RAM (NRAM), magnetoresistive RAM (MRAM), phase change RAM (PRAM), racetrack memory, memristor memory, etc. As noted above, the memory may store program instructions that can be executed by the computing complex 1020 to cause the computing device to perform the functionality described herein.

[0259] Graphics unit 1075 may include one or more processors, such as one or more graphics processing units (GPUs). For example, graphics unit 1075 may receive graphics-oriented instructions, such as Metal or Instructions. Graphics unit 1075 may execute dedicated GPU instructions or perform other operations based on the received graphics-oriented instructions. Graphics unit 1075 may generally be configured to process large data blocks in parallel and may construct images in a frame buffer for output to a display, which may be included in the device or may be a separate device. Graphics unit 1075 may include transformation, lighting, triangle, and rendering engines in one or more graphics processing pipelines. Graphics unit 1075 may output pixel information for displaying an image. In various embodiments, graphics unit 1075 may include a programmable shader circuit system, which may include a highly parallel execution core configured to execute graphics programs, which may include pixel tasks, vertex tasks, and computational tasks (which may be graphics-related or may not be graphics-related).

[0260] The display unit 1065 may be configured to read data from the frame buffer and provide a stream of pixel values ​​for display. In some embodiments, the display unit 1065 may be configured as a display pipeline. In addition, the display unit 1065 may be configured to blend multiple frames to produce an output frame. In addition, the display unit 1065 may include one or more interfaces (e.g., a touch screen or an external display) for coupling to a user display (e.g., or embedded DisplayPort (eDP).

[0261] The I / O bridge 1050 may include various elements configured to implement, for example, Universal Serial Bus (USB) communications, security, audio, and low-power always-on functionality. The I / O bridge 1050 may also include interfaces such as, for example, pulse width modulation (PWM), general purpose input / output (GPIO), serial peripheral interface (SPI), and inter-integrated circuit (I2C). Various types of peripherals and devices may be coupled to the device 1000 via the I / O bridge 1050.

[0262] In some embodiments, device 1000 includes a network interface circuit system (not explicitly shown) that can be connected to structure 1010 or I / O bridge 1050. The network interface circuit system can be configured to communicate via various networks, which can be wired networks, wireless networks, or both. For example, the network interface circuit system can be configured to communicate via a wired local area network, a wireless local area network (e.g., via Wi-Fi TM ) or a wide area network (e.g., the Internet or a virtual private network). In some embodiments, the network interface circuit system is configured to communicate via one or more cellular networks using one or more radio access technologies. In some embodiments, the network interface circuit system is configured to use device-to-device communication (e.g., or Wi-Fi TM In various embodiments, the network interface circuit system can provide device 1000 with connectivity to various types of other devices and networks.

[0263] Example Applications

[0264] Now go to Fig.11, various types of systems that may include any of the circuits, devices, or systems discussed above are shown. The system or device 1100, which may incorporate or otherwise utilize one or more of the techniques described herein, may be used in a wide range of fields. For example, the system or device 1100 may be used as part of the hardware of a system such as a desktop computer 1110, a laptop computer 1120, a tablet computer 1130, a cellular or mobile phone 1140, or a television 1150 (or a set-top box coupled to a television).

[0265] Similarly, the disclosed elements can be used in a wearable device 1160, such as a smart watch or a health monitoring device. In many embodiments, a smart watch can implement a variety of different functions—for example, access to email, cellular service, calendar, health monitoring, etc. A wearable device can also be designed to perform only health monitoring functions, such as monitoring a user's vital signs, performing epidemiological functions such as contact tracing, providing communications to emergency medical services, etc. Other types of devices are also contemplated, including devices worn around the neck, devices implantable in the human body, glasses or helmets designed to provide computer-generated reality experiences, such as those based on augmented reality and / or virtual reality, etc.

[0266] The system or device 1100 may also be used in various other environments. For example, the system or device 1100 may be used in the environment of a server computer system (such as a dedicated server) or on shared hardware that implements a cloud-based service 1170. Further, the system or device 1100 may be implemented in a wide range of dedicated everyday devices, including common devices 1180 in the home, such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is generally referred to as the "Internet of Things" (IoT). Elements may also be implemented in various modes of transportation. For example, the system or device 1100 may be used for control systems, guidance systems, entertainment systems, etc. of various types of vehicles 1190.

[0267] Fig.11 The applications illustrated in the examples are merely exemplary and are not intended to limit the potential future applications of the disclosed system or device. Other exemplary applications include, but are not limited to: portable game devices, music players, data storage devices, unmanned aerial vehicles, etc.

[0268] Exemplary computer readable media

[0269] The present disclosure has described various exemplary circuits in detail above. It is intended that the present disclosure covers not only embodiments including such circuit systems, but also computer-readable storage media including design information specifying such circuits. Therefore, the present disclosure is intended to support claims that cover not only devices including the disclosed circuit systems, but also storage media that specify the circuit systems in a format that programs a computing system to generate a simulation model of a hardware circuit, programs a computing system configured to generate hardware (e.g., an integrated circuit) including the disclosed circuit systems, and the like. Claims to such storage media are intended to cover, for example, entities that generate circuit designs but do not perform complete operations themselves (such as design simulation, design synthesis, circuit manufacturing, etc.).

[0270] Fig.12 is a block diagram illustrating an exemplary non-transitory computer-readable storage medium storing circuit design information according to some embodiments. In the illustrated embodiment, computing system 1240 is configured to process the design information. This may include executing instructions included in the design information, interpreting instructions included in the design information, compiling, transforming or otherwise updating the design information, etc. Thus, in some embodiments, the design information controls computing system 1240 (e.g., by programming computing system 1240) to perform various operations discussed below.

[0271] In the illustrated example, computing system 1240 processes the design information to generate both a computer simulation model of hardware circuit 1260 and lower-level design information 1250. In other embodiments, computing system 1240 may generate only one of these outputs, may generate other outputs based on the design information, or both. With respect to computer simulation, computing system 1240 may execute instructions of a hardware description language, which may include register transfer level (RTL) code, behavioral code, structural code, or some combination thereof. The simulation model may perform the functionality specified by the design information, facilitate verification of the functional correctness of the hardware design, generate power consumption estimates, generate timing estimates, and the like.

[0272] In the illustrated example, computing system 1240 also processes the design information to generate lower-level design information 1250 (e.g., gate-level design information, netlists, etc.). As shown, this may include synthesis operations such as building a multi-level network, optimizing the network using technology-independent techniques, technology-dependent techniques, or both, and outputting a gate network (with potential constraints based on available gate-to-technology libraries, sizing, delay, power, etc.). Based on lower-level design information 1250 (and potentially other inputs), semiconductor manufacturing system 1220 is configured to manufacture integrated circuit 1230 (which may correspond to the functionality of simulation model 1260). Note that computing system 1240 may generate different simulation models based on various levels of description of design information (including information 1250, 1215, etc.). Data representing design information 1250 and model 1260 may be stored on medium 1210 or on one or more other media.

[0273] In some embodiments, lower-level design information 1250 controls (e.g., programs) semiconductor fabrication system 1220 to fabricate integrated circuit 1230. Thus, when processed by the fabrication system, the design information can program the fabrication system to fabricate circuits including the various circuitry disclosed herein.

[0274] The non-transitory computer-readable storage medium 1210 may include any of a variety of suitable types of memory devices or storage devices. The non-transitory computer-readable storage medium 1210 may be an installation medium, for example, a CD-ROM, a floppy disk, or a tape device; a computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, RambusRAM, etc.; a non-volatile memory, such as flash memory, a magnetic medium, for example, a hard drive or an optical storage device; a register or other similar type of memory element, etc. The non-transitory computer-readable storage medium 1210 may also include other types of non-transitory memory or combinations thereof. Therefore, the non-transitory computer-readable storage medium 1210 may include two or more memory media; such media may reside in different locations—for example, in different computer systems connected by a network.

[0275] The design information 1215 may be specified using any of a variety of suitable computer languages, including hardware description languages, such as, but not limited to, VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, and the like. The formats of the various design information may be identified by one or more applications executed by the computing system 1240, the semiconductor manufacturing system 1220, or both. In some embodiments, the design information may also include one or more cell libraries that specify the synthesis, layout, or both of the integrated circuit 1230. In some embodiments, the design information is specified in whole or in part in the form of a netlist that specifies the cell library elements and their connectivity. Taken alone, the design information discussed herein may or may not include sufficient information for manufacturing the corresponding integrated circuit. For example, the design information may specify the circuit elements to be manufactured, but not their physical layout. In this case, the design information may need to be combined with the layout information to actually manufacture the specified circuit system.

[0276] In various embodiments, integrated circuit 1230 may include one or more custom macrocells, such as memory, analog or mixed signal circuits, etc. In this case, the design information may include information related to the included macrocells. Such information may include, but is not limited to, schematic capture databases, mask design data, behavioral models, and device or transistor level netlists. The mask design data may be formatted according to a graphic data system (GDSII) or any other suitable format.

[0277] Semiconductor manufacturing system 1220 may include any of a variety of suitable elements configured to manufacture integrated circuits. This may include, for example, elements for depositing semiconductor material (e.g., on a wafer that may include a mask), removing material, changing the shape of deposited material, modifying material (e.g., by doping the material or modifying the dielectric constant using ultraviolet treatment), etc. Semiconductor manufacturing system 1220 may also be configured to perform various tests of the manufactured circuits for proper operation.

[0278] In various embodiments, integrated circuit 1230 and model 1260 are configured to operate according to the circuit design specified by design information 1215, which may include performing any of the functionality described herein. For example, integrated circuit 1230 may include Figure 1 , FIG. 6A to FIG. 6C Any of the various elements shown in . In addition, integrated circuit 1230 can be configured to perform various functions described herein in conjunction with other components. In addition, the functionality described herein can be performed by multiple connected integrated circuits.

[0279] As used herein, a phrase of the form “design information specifying a design of a circuit configured to…” does not imply that the circuit in question must be manufactured in order to satisfy the element. Rather, the phrase indicates that the design information describes a circuit that, when manufactured, will be configured to perform the indicated actions or will include the specified components. Similarly, the statement that “instructions of a hardware description programming language are “executable” to program a computing system to generate a computer simulation model” does not mean that the instructions must be executed in order to satisfy the element, but rather that the characteristics of those instructions are specified. In this case, additional features associated with the model (or the circuit represented by the model) may similarly be related to the characteristics of those instructions. Thus, an entity that sells a computer-readable medium having instructions that satisfy the described characteristics may be providing an infringing product even if another entity actually executes those instructions on the medium.

[0280] Note that a given design, at least in the context of digital logic, may be implemented using a number of different gate arrangements, circuit technologies, etc. As one example, different designs may select or connect gates based on design tradeoffs (e.g., to focus on power consumption, performance, circuit area, etc.). Furthermore, different manufacturers may have proprietary libraries, gate designs, physical gate implementations, etc. Different entities may also use different tools to process design information at various levels (e.g., from behavioral specifications to physical layout of gates).

[0281] However, once a digital logic design is specified, those skilled in the art do not need to perform extensive experimentation or research to determine these implementations. Instead, those skilled in the art understand procedures for reliably and predictably generating one or more circuit implementations that provide the functionality described by the design information. Different circuit implementations may affect the performance, area, power consumption, etc. of a given design (potentially with tradeoffs between different design goals), but the logic functionality does not change between different circuit implementations of the same circuit design.

[0282] In some embodiments, the instructions included in the design information instructions provide RTL information (or other higher-level design information) and are executable by the computing system to synthesize a gate-level netlist representing a hardware circuit based on the RTL information as input. Similarly, the instructions can provide behavioral information and can be executed by the computing system to synthesize a netlist or other lower-level design information. The lower-level design information can program the manufacturing system 1220 to manufacture the integrated circuit 1230.

[0283] ***

[0284] The present disclosure includes references to "an embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different specific implementations or examples of the disclosed concepts. References to "an embodiment," "one embodiment," "a particular embodiment," etc. do not necessarily refer to the same embodiment. A large number of possible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of the present disclosure.

[0285] The present disclosure may discuss potential advantages that may be generated by the disclosed embodiments. Not all of these implementations will necessarily exhibit any or all of the potential advantages. Whether a particular implementation achieves an advantage depends on many factors, some of which are outside the scope of the present disclosure. In fact, there are many reasons why a particular implementation that falls within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular implementation may include other circuit systems outside the scope of the present disclosure, which, in combination with one of the disclosed embodiments, negate or reduce one or more of the disclosed advantages. In addition, suboptimal design execution of a particular implementation (e.g., a specific implementation technique or tool) may also negate or reduce the disclosed advantages. Even assuming a specific implementation of the technology, the realization of the advantages may still depend on other factors, such as the environmental conditions in which the specific implementation is deployed. For example, the input provided to a particular implementation may prevent one or more problems solved in the present disclosure from occurring in a particular occasion, and as a result, the benefits of its solution may not be realized. In view of the existence of possible factors external to the present disclosure, it is hereby clarified that any potential advantages described herein should not be construed as claim limitations that must be met in order to prove infringement. Instead, the identification of such potential advantages is intended to illustrate the types of improvements available to designers who benefit from the present disclosure. Permanently describing such advantages (eg, stating that a particular advantage "may occur") is not intended to convey a doubt as to whether such advantage can actually be achieved, but rather to recognize that achievement of such advantage typically depends on technical realities of additional factors.

[0286] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on the present disclosure, even if only a single example is described with respect to a particular feature. The embodiments disclosed by the present invention are intended to be illustrative and non-restrictive, without any contrary statement in the present disclosure. Therefore, the present application is intended to allow claims covering the disclosed embodiments, as well as such alternatives, modifications and equivalents, which will be apparent to those skilled in the art who are aware of the beneficial effects of the present disclosure.

[0287] For example, features in this application may be combined in any suitable manner. Accordingly, new claims may be made during the prosecution of this application (or an application claiming priority thereto) for any such combination of features. In particular, with reference to the appended claims, features of dependent claims may be combined, where appropriate, with features of other dependent claims, including claims that are dependent on other independent claims. Similarly, features from corresponding independent claims may be combined, where appropriate.

[0288] Thus, while the appended dependent claims may be drafted such that each dependent claim is dependent upon a single other claim, additional dependencies are also contemplated. Any combination of dependent features consistent with the present disclosure is contemplated and may be claimed in this or another application. In short, the combinations are not limited to those specifically recited in the appended claims.

[0289] It is also contemplated that claims drafted in one format or legal type (eg, apparatus) are intended to support corresponding claims in another format or legal type (eg, method), where appropriate.

[0290] ***

[0291] Because this disclosure is a legal document, various terms and phrases may be subject to regulatory and judicial interpretation. Notice is hereby given that the definitions provided in the following paragraphs and throughout this disclosure will be used to determine how to interpret claims drafted based on this disclosure.

[0292] Unless the context clearly dictates otherwise, reference to an item in the singular (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more." Thus, reference to "an item" in a claim does not exclude additional instances of that item without the accompanying context. A "plurality" of an item refers to a group of two or more items.

[0293] The word "may" is used herein in a permissive sense (ie, having the potential to, being able to), rather than the mandatory sense (ie, must).

[0294] The terms "including" and "comprising" and forms thereof are open ended and mean "including, but not limited to."

[0295] When the term "or" is used in this disclosure with respect to a list of options, it will generally be understood to be used in an inclusive sense unless the context provides otherwise. Thus, the expression "x or y" is equivalent to "x or y, or both," and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as "either x or y, but not both" make it clear that "or" is used in an exclusive sense.

[0296] The expressions "w, x, y, or z, or any combination thereof" or "at least one of ... w, x, y, and z" are intended to cover all possibilities involving individual elements up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element in the set (e.g., w but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. The phrase "at least one of ... w, x, y, and z" thus refers to at least one element in the set [w, x, y, z], thereby covering all possible combinations in the list of elements. The phrase should not be interpreted as requiring the presence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0297] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context provides otherwise, different labels used for a feature (e.g., "a first circuit," "a second circuit," "a particular circuit," "a given circuit," etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0298] The phrase "based on" or is used to describe one or more factors that influence a determination. This term does not exclude the possibility that additional factors may influence the determination. That is, a determination may be based only on the specified factors or on the specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor such as C. This phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0299] The phrases "in response to" and "in response to" describe one or more factors that trigger an effect. The phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, either in conjunction with the specified factors or independently of the specified factors. That is, the effect may be responsive to these factors alone, or may be responsive to the specified factors as well as other unspecified factors. Consider the phrase "A is performed in response to B." The phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. The phrase does not exclude that the execution of A may also be responsive to certain other factors, such as C. The phrase also does not exclude that the execution of A may be performed jointly in response to B and C. This phrase is also intended to cover embodiments in which A is performed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially in response to." Similarly, the phrase "in response to" is synonymous with the phrase "at least partially in response to."

[0300] Within the present disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured to" perform one or more tasks or operations. This expression—[an entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a physical thing). More specifically, this expression is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure may be considered to be "configured to" perform a task even if the structure is not currently being operated. Therefore, an entity described or stated as "configured to" perform a task refers to a physical thing used to implement the task, such as a device, a circuit, a system with a processor unit, and a memory storing executable program instructions, etc. This phrase is not used herein to refer to an intangible thing.

[0301] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform those tasks / operations, even if not specifically stated.

[0302] The term "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA would not be considered "configured to" perform a particular function. However, the unprogrammed FPGA may be "configurable to" perform that function. After appropriate programming, the FPGA may then be considered "configured to" perform the particular function.

[0303] For purposes of a U.S. patent application based on the present disclosure, stating in a claim that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. §112(f) for that claim element. If the applicant wishes to invoke section 112(f) during prosecution of a U.S. patent application based on the present disclosure, it would use the “means for [performing the function]” construct to phrase the claim element.

[0304] ***

[0305] Different "circuits" may be described in the present disclosure. These circuits or "circuitry" constitute hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. The circuitry may be custom designed or taken from a standard library. In various specific implementations, the circuitry may include digital components, analog components, or a combination of both, as appropriate. Certain types of circuits may be generally referred to as "units" (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units are also referred to as circuitry.

[0306] Thus, the disclosed circuits / units / components and other elements illustrated in the drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the functionality of the circuit. For example, a particular "decode unit" may be described as performing the function of "processing an opcode for an instruction and routing the instruction to one or more of a plurality of functional units," meaning that the decode unit is "configured to" perform that function. For one skilled in the computer arts, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0307] In various embodiments, as described in the preceding paragraphs, circuits, units, and other elements may be defined by the functions or operations they are configured to implement. The arrangement relative to each other and such circuits / units / components and the way they interact form a microarchitecture definition of hardware, which is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Therefore, the microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations can be derived, all of which fall into the broader structure described by the microarchitecture definition. That is, a technician with a microarchitecture definition provided in accordance with the present disclosure can implement the structure by coding a description of a circuit / unit / component in a hardware description language (HDL) such as Verilog or VHDL without excessive experimentation and using the application of ordinary technicians. HDL descriptions are often expressed in a way that can be displayed as functional. However, for those skilled in the art, the HDL description is a way to convert the structure of a circuit, unit, or component into the next level of specific implementation details. Such HDL descriptions may take the form of behavioral code (which is generally non-synthesizable), register transfer language (RTL) code (which is generally synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). The HDL description may be sequentially synthesized for a library of cells designed for a given integrated circuit manufacturing technology, and may be modified for timing, power, and other reasons to obtain a final design database that is sent to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuits or portions thereof may also be custom designed in a schematic editor and captured into an integrated circuit design along with the synthesized circuitry. The integrated circuit may include transistors and other circuit elements (e.g., passive elements such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some embodiments may implement multiple integrated circuits coupled together to implement the hardware circuit, and / or discrete elements may be used in some embodiments. Alternatively, the HDL design may be synthesized into a programmable logic array such as a field programmable gate array (FPGA), and may be implemented in an FPGA. This decoupling between the design of a set of circuits and the subsequent low-level implementation of those circuits often leads to a situation where a circuit or logic designer never specifies a specific set of structures for the low-level implementation beyond a description of what the circuits are configured to do, because that process is performed at different stages of the circuit implementation process.

[0308] The fact that many different low-level combinations of circuit elements can be used to achieve the same specification of a circuit results in a large number of identical structures for that circuit. As noted, these low-level circuit implementations can vary depending on variations in manufacturing technology, the foundry selected to manufacture the integrated circuit, the cell libraries provided for a particular project, etc. In many cases, the selection made by different design tools or methodologies to produce these different implementations can be arbitrary.

[0309] Furthermore, for a given embodiment, a single implementation of a particular functional specification of a circuit typically includes a large number of devices (e.g., millions of transistors). Thus, the shear volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single embodiment, let alone the large number of equivalent possible implementations. For this reason, the present disclosure describes the structure of the circuit using functional shorthand commonly used in the industry.

Claims

1. A device, comprising: A processor, the processor comprising: a grant table circuit configured to store a plurality of permissions for access to memory, wherein the grant table circuit is indexed by a specific permission table index corresponding to a specific instruction to provide specific permissions for a specific memory access by the specific instruction; and a control circuit coupled to the grant table circuit and configured to generate the particular grant table index based on: a first value corresponding to a first memory address indicated by the particular instruction; and A second value corresponding to a second memory address at which the particular instruction is stored.

2. The device according to claim 1, further comprising: A translation lookaside buffer TLB is coupled to the control circuit, wherein the TLB is configured to store one or more of the first value and the second value.

3. The apparatus of claim 1 , wherein the first value is stored in a page table in association with a first physical page number to which the first memory address is converted, and wherein the second value is stored in the page table in association with a second physical page number to which the second memory address is converted. 4 . The apparatus of claim 1 , wherein the control circuit is configured to generate the specific permissions table index by concatenating the first value and the second value.

5. The apparatus of claim 4, wherein the particular grant table index is a secondary index, and wherein the control circuitry is configured to access a particular set of permissions from the grant table circuitry using the secondary index, wherein the particular set of permissions is a permissions mask; wherein the control circuit is configured to generate a primary index for the particular instruction based on a third value corresponding to the first memory address; and wherein the control circuitry is configured to retrieve a base memory permissions set from the grant table circuitry using the primary index and to retrieve the permissions mask from the grant table circuitry using the secondary index; and Wherein the control circuit is configured to combine the base memory permission set and the permission mask to obtain a final memory permission set for the specific instruction.

6. The apparatus of claim 1, wherein the particular instruction is a control flow instruction, wherein the first memory address is a target of the control flow instruction.

7. The apparatus of claim 6 , wherein in response to the target of the control flow instruction being a load-store instruction, the control circuitry is configured to generate a different permission table index for the target of the control flow instruction based on: a third value corresponding to a third memory address accessed by the target of the control flow instruction; and A fourth value corresponding to a fourth memory address at which the target of the control flow instruction is stored.

8. The device according to claim 1, further comprising: A secondary execution privilege table circuit is configured to store a plurality of secondary execution privilege values, wherein: The secondary execution privilege table circuit is indexed by a specific secondary execution privilege index corresponding to the specific instruction to provide a specific secondary execution privilege value for the specific instruction; The particular secondary execution privilege value defines a permissible set of a plurality of instruction groups that can be executed from the second memory address; and The control circuitry is configured to selectively permit the processor to execute the particular instruction when the particular instruction is in the permissible set of the plurality of instruction groups defined by the particular secondary execution privilege value.

9. An apparatus according to claim 8, wherein the specific secondary execution privilege index is associated with a specific page table entry to which the second memory address is mapped; and wherein the control circuit is further configured to selectively permit the processor to execute the specific instruction based on the primary execution privilege associated with the specific page table entry.

10. The apparatus of claim 1, wherein the permission table circuit is configured to store a plurality of permission tables, the plurality of permission tables specifying different permissions for the particular instruction; The control circuit is configured to obtain permission for the specific instruction in the following manner: selecting a permission table from among the plurality of permission tables based on an execution mode of the processor; and A permission for the particular instruction is retrieved from the selected permission table using the particular permission table index.

11. A method comprising: receiving, in a processor of a computer system, a specific instruction to be executed by an execution pipeline circuit of the processor, the specific instruction including a reference to a first memory address and located at a second memory address; storing, by the processor, a plurality of permissions for access to a memory of the computer system in a permissions table, wherein the permissions table is indexed by a permissions table index; as well as A specific permissions table index for the specific instruction is generated by the processor based on: a first value corresponding to the first memory address; as well as a second value corresponding to the second memory address; Retrieving, by the processor, a specific permission for the specific instruction from the permission table using the specific permission table index; as well as Final memory permissions based on the specific permissions are enforced by the processor during execution of the specific instructions.

12. The method of claim 11, wherein the specific permission is a permission mask, the method further comprising: determining base memory permissions from a permissions table lookup based on a third value corresponding to said first memory address; as well as The final memory permission is generated from the base memory permission and the specific permission.

13. The method according to claim 11, further comprising: Execution permissions for the particular instruction are determined from a permissions table lookup based on a fourth value corresponding to the second memory address.

14. The method according to claim 11, further comprising: Secondary execution privileges for the particular instruction are determined from a permissions table lookup based on a fifth value corresponding to the second memory address, the secondary execution privileges defining which of a plurality of permissions groups are permitted to execute from the second memory address.

15. The method according to claim 11, further comprising: The permission table is selected from a set of permission tables based on a current execution mode of the processor.

16. The method of claim 11, wherein the permission table defines two or more different memory permissions for accessing a particular memory location from different code locations.

17. A device, comprising: A processor configured to execute computer program instructions, the processor comprising: a grant table circuit configured to store a plurality of permissions for access to the memory in a set of permission tables, wherein the set of permission tables is indexed by a permission table index; An execution pipeline circuit configured to receive a specific instruction for execution, the specific instruction specifying a first memory address to be accessed by the specific instruction, and the specific instruction is located at a second memory address, wherein a control circuit of the execution pipeline circuit is configured to: generating a specific permission table index for the specific instruction based on the first memory address and the second memory address; retrieving from the grant table circuitry a specific permission for the specific instruction from the plurality of permissions using the specific permission table index, the specific permission being specific to code executing at the second memory address and accessing a memory location at the first memory address; and Final memory permissions based on the specific permissions are enforced during execution of the specific instructions.

18. The apparatus of claim 17, wherein the execution pipeline circuit is configured to retrieve the specific permission by: selecting a grant table from the grant table circuitry, based on an execution mode of the processor, a grant table of a plurality of grant tables; and The selected permissions table is accessed using the specific permissions table index to retrieve the specific permissions.

19. The apparatus of claim 18, wherein the execution mode and the particular permissions table index are from a previous clock cycle of the processor.

20. The apparatus of claim 18, wherein the control circuitry comprises a mode checking circuitry configured to determine whether a mode change specified by an instruction is permitted prior to propagating a new mode value throughout the execution pipeline circuitry.

21. A device, comprising: A processor, the processor comprising: a permission table circuit configured to store a plurality of secondary execution privileges, wherein the permission table circuit is indexed by a specific secondary execution privilege index corresponding to a specific instruction to provide a specific secondary execution privilege value for the specific instruction, the specific secondary execution privilege value defining which instruction groups of a plurality of instruction groups of an instruction set architecture ISA of the processor are executable from a first memory address at which the specific instruction is stored; and A control circuit is coupled to the permission table circuit and is configured to selectively permit the processor to execute the specific instruction when the specific instruction is in a specific instruction group indicated as executable by the specific secondary execution privilege value.

22. An apparatus according to claim 21, wherein the control circuit is configured to permit the processor to execute the specific instructions based on that the specific secondary execution privilege value indicates execution privileges for the specific instruction group, and wherein the control circuit is configured to prevent the processor from executing the specific instructions based on that the specific secondary execution privilege value does not indicate execution privileges for the specific instruction group.

23. The apparatus of claim 22, wherein the control circuitry is configured to cause a signaling exception in response to the particular secondary execution privilege value not indicating execution privileges for the particular instruction.

24. The apparatus of claim 21, wherein the particular secondary execution privilege index is associated with a page table entry to which the first memory address is mapped.

25. The apparatus of claim 24, wherein the control circuitry is further configured to selectively permit the processor to execute the particular instruction based on a primary execution privilege associated with the page table entry.

26. The apparatus of claim 21 , wherein the control circuit is further configured to enforce memory permission in response to the particular instruction being a memory access instruction indicated as executable by the particular secondary execution privilege value, wherein the control circuit is configured to obtain the memory permission using a memory permission index generated based on the first memory address and a target memory address specified by the memory access instruction.

27. The apparatus of claim 21, wherein the particular secondary execution privilege value is stored in a particular permission table of a plurality of permission tables, wherein the control circuitry is configured to select the particular permission table based on an execution mode of the processor.

28. The apparatus of claim 27, wherein the control circuitry comprises a mode checking circuit configured to determine whether a mode change instruction is authorized before changing the execution mode of the processor.

29. The apparatus of claim 21, wherein the control circuit is configured to determine that the specific instruction is in the specific instruction group indicated by the specific secondary execution privilege value based on an opcode of the specific instruction and a mapping of opcodes of the ISA to instruction groups.

30. The apparatus of claim 21, wherein the control circuitry is configured to write to the grant table circuitry to change the set of instruction groups designated as executable at the first memory address.

31. A method comprising: receiving, in a processor of a computer system, a specific instruction of an instruction set architecture (ISA) of the processor, the specific instruction being located at a first memory address of a memory of the computer system; storing, by the processor, a plurality of secondary execution privileges in a permission table, the plurality of secondary execution privileges defining, for instructions stored at different memory locations, which instruction groups of a plurality of instruction groups of the ISA are executable from the memory locations; generating, by the processor, a specific secondary execution privilege index for the specific instruction based on a first value corresponding to the first memory address; retrieving, by the processor, from the permission table a specific secondary execution privilege value corresponding to the first memory address using the specific secondary execution privilege index; as well as A determination is made by the processor whether execution of the specific instruction is permitted based on the specific secondary execution privilege value and the specific instruction.

32. The method of claim 31, wherein the determining is further based on a primary execution permission obtained by indexing into a lookup table using a primary index, the primary index being obtained using the first memory address.

33. The method of claim 32, wherein the primary execution permissions indicate whether any code is permitted to execute at the first memory address, wherein the specific secondary execution privilege value indicates which instruction groups of the ISA are permitted to execute at the first memory address, and wherein the determining comprises satisfying both the primary execution permissions and the specific secondary execution privilege value.

34. The method of claim 31, wherein the permission table is selected from a plurality of permission tables using an execution mode of the processor.

35. The method of claim 31 , further comprising: The permission table is modified by the processor to change which instruction groups of the plurality of instruction groups are executable from the first memory address.

36. An apparatus, comprising: A processor, the processor being configured to: receiving a specific instruction for execution at an execution pipeline, the specific instruction being located at a first virtual memory address; accessing an entry of a page table using the first virtual memory address, the entry storing a physical page number to which the first virtual memory address is mapped and an indication of a particular secondary execution privilege value, the particular secondary execution privilege value specifying which instruction groups of a plurality of instruction groups of an instruction set architecture ISA of the processor are permitted to execute at the first virtual memory address; as well as A determination is made whether execution of the specific instruction is permitted based on the specific secondary execution privilege value and a determination of which instruction group the specific instruction belongs to.

37. The apparatus of claim 36, wherein the processor is further configured to determine whether to permit execution of the particular instruction using a primary execution privilege accessed from a lookup table using a primary index stored in the entry of the page table.

38. An apparatus according to claim 37, wherein the indication of the specific secondary execution privilege value is a secondary index into a specific secondary execution privilege table among a plurality of secondary execution privilege tables, the specific secondary execution privilege table being selected by a mode value indicating an execution mode of the processor, and the secondary index specifying a location in the specific secondary execution privilege table where the specific secondary execution privilege value is stored.

39. The apparatus of claim 36, wherein the processor is configured to enforce memory permissions in response to the particular instruction being a memory access instruction by: generating a memory permission index based on the first virtual memory address and a target virtual memory address specified by the specific instruction; retrieving a memory grant value using the memory grant index; and The memory permission value for the particular instruction is enforced.

40. The apparatus of claim 36, wherein the processor is configured to signal an exception rather than permitting execution of the particular instruction based on determining from the particular secondary execution privilege value that the instruction group of the particular instruction is not permitted to execute from the first virtual memory address.

Images