Embodiments of the inventive subject matter relate to methods and apparatus for controlling access to shared system resources.
In current electronic systems, semaphores have been used to provide a mechanism for controlling concurrent accesses to shared memory regions. When used properly, semaphores help to ensure that shared memory regions are accessed serially, rather than concurrently, so that the shared memory regions may remain coherent. For example, in a multiple-processor system, before a processor accesses (e.g., updates or writes to) a shared memory region, the processor may be required, by software convention, to determine whether a semaphore associated with the shared memory region currently is locked by another processor. If not, the processor may lock the semaphore and access the shared memory region, and other processors should avoid concurrent accesses to the shared memory region. Only the processor that locked the semaphore may access the shared memory region and then unlock it after the access has been completed. Once the semaphore has been unlocked, another processor may attempt to lock the semaphore in order to reserve access to the shared memory region.
Proper system operation is guaranteed only when the processors use the semaphores in the correct manner. More specifically, each of the processors must follow the implied protocol associated with locking and unlocking semaphores in conjunction with making accesses to shared memory regions. Failure to follow the required protocols, either because of a programming error or malicious software, may manifest itself in any of a number of error conditions (e.g., data corruption, system hangs, system crashes, and so on). In the processor industry, requirements with respect to system fault tolerance continue to increase.
Embodiments described herein include methods and apparatus for enforcing semaphore access control of shared system resources. The various embodiments may better ensure coherent memory accesses in multiple-processor systems, even with the ever-present risk of erroneous or malicious software that may attempt to access shared memory in a non-coherent manner. As will be described in more detail below, semaphores may be explicitly associated, in software, with region descriptors for shared system resources. Essentially, each region descriptor specifies a range of one or more addresses that defines a shared system resource, and default access permissions for various system components (e.g., processors or other components) with respect to the shared system resource. When a system component issues a request to access an address that falls within the range of addresses that define a shared system resource, a memory protection unit determines whether the system component has the appropriate permissions to perform the access. If so, the memory protection unit may grant the access request. If not, the memory protection unit may deny the access request.
According to an embodiment, the memory protection unit receives signals from a semaphores module, which indicate whether or not a system component has locked a semaphore associated with a shared system resource. Based on the semaphore signals, the memory protection unit potentially may modify the default access permissions codified in the corresponding region descriptor, in order to ensure that only a system component that has properly locked a semaphore may be granted an access request to the shared system resource.
The various embodiments may be implemented in any of a number of system architectures, and
Communication between DACs 102-104, semaphores module 108, MPU 110, RAM 112, flash array 114, and peripheral modules 120, 122 is implemented via the system bus 106 and peripheral busses 124, 126, according to an embodiment. DACs 102-104 may function as bus masters (e.g., DACs 102-104 are connected to system bus 106 via master ports), and RAM 112, flash array 114, and peripheral modules 120, 122 may function as slaves (e.g., RAM 112, flash array 114, and peripheral bus 124 are connected to system bus 106 via slave ports), for example. As bus masters, DACs 102-104 may attempt to access memory locations (e.g., RAM 112 and flash array 114) via the system bus 106. Similarly, DACs 102-104 may access peripheral modules 120, 122, semaphores module 108, and MPU 110 via system bus 106 and peripheral busses 124, 126. Each DAC 102-104 has a unique bus master number, which the DAC 102-104 may provide on the system bus 106 (along with an access address) when the DAC 102-104 makes an access attempt to a memory location or other module. In other embodiments, the communication bus structure may be different from that depicted in
Although the term “bus” is used herein, it is to be understood that a “bus” essentially is a type of interconnect between system entities, which facilitates communication of data, control signals, or other signals between the system entities. Accordingly, the use of the term “bus” herein is not meant to be limiting, but should be interpreted broadly as any of a variety of types of interconnects that are sufficient to provide for communication between system entities. For example, system bus 106 (or “interconnect”) and peripheral busses 124, 126 (or “interconnects”) may be, for example, 32-bit wide busses, although system bus 106 and/or peripheral busses 124, 126 alternatively may be wider or narrower, as well. Each of busses 106, 124, 126 may implement a bus controller (not illustrated) in order to perform bus protocol conversions, bus width conversions, operating frequency conversions, or other signal alterations, although this is not required. In addition, each of busses 106, 124, 126 includes address lines, data lines, and various control lines (e.g., a read/write control signal line, a bus clock line, a transfer size signal line, and/or a wait signal line). Conversely, peripheral busses 124, 126 provide bus protocols that enable the DACs 102-104 (e.g., processor cores) to access various peripheral registers (e.g., registers of peripherals 120, 122) and programming model registers (e.g., registers 202-204,
As used herein, the terms “data access component” and “DAC” mean a programmable hardware module that is adapted to execute software instructions that initiate data transfers with shared system resources. A “shared system resource” includes any memory location(s), register(s), and peripheral(s) that are capable of being accessed by multiple DACs 102-104 (e.g., ranges of addressable locations and/or single addressable locations within RAM 112, flash array 114, and peripherals 120, 122).
DACs 102-104 may include any combination of hardware modules selected from a group that includes processor cores (e.g., microcontrollers, microprocessors, and/or digital signal processors (DSPs)), non-core processing elements, Direct Memory Access (DMA) units, and/or other hardware modules that are programmable and adapted to execute software instructions that initiate data transfers between a DAC 102-104 and a shared system resource. As indicated in
DACs 102-104 are adapted to execute software instructions (e.g., machine-readable code) which, among other things, may require access to shared system resources. In order to access a shared system resource, a DAC 102-104 issues an access request over system bus 106. The access request specifies the access type (e.g., read, write, or execute), and at least one address corresponding to the shared system resource.
Prior to issuing an access request, each DAC 102-104 attempts to lock (or “obtain ownership of”) a semaphore associated with the shared system resource. According to an embodiment, semaphores module 108 is configured to implement a plurality of such semaphores, and DACs 102-104 interact with the semaphores module 108 in order to lock and unlock the semaphores. The state of each semaphore (e.g., unlocked or locked by a particular DAC 102-104) is maintained in a semaphore “gate” (or semaphore register) (e.g., semaphore gates 202-204,
To attempt to lock a semaphore, a “lock-requesting” DAC 102-104 may attempt to write a value (e.g., an encoded value representing an identity of the lock-requesting DAC) into a particular semaphore register via system bus 106 and peripheral bus 126. The semaphores module 108 will allow the value to be written to the semaphore register only when the semaphore is in an idle state. Otherwise (e.g., when another DAC 102-104 already has locked the semaphore), the semaphores module 108 will not update the semaphores register with the value that the lock-requesting DAC 102-104 attempted to write. To determine whether the lock-requesting DAC 102-104 successfully locked the semaphore, the lock-requesting DAC 102-104 reads (via system bus 106 and peripheral bus 126) a value from the same semaphore register that it attempted to write. When the read value is the same as the value that the lock-requesting DAC 102-104 attempted to write to the semaphore register, the lock-requesting DAC 102-104 has successfully locked the semaphore. When the read value is different from the value that the lock-requesting DAC 102-104 attempted to write to the semaphore register, the lock-requesting DAC 102-104 may assume that it was unable to lock the semaphore (e.g., another DAC 102-104 already has locked the semaphore).
When a DAC 102-104 has properly locked a semaphore associated with a shared system resource, the DAC 102-104 may issue access requests of various access types (e.g., read, write, and/or execute) over system bus 106, in an attempt to access the shared system resource. To issue an access request, for example, a DAC 102-104 provides an address on the address lines of system bus 106, which identifies a location within the shared system resource (e.g., RAM 112, flash array 114, or a peripheral 120, 122). For a write-type of access request, the DAC 102-104 also provides a data value on data lines of system bus 106. For a read-type of data access request, the DAC 102-104 may attempt to read a data value from the data lines of system bus 106, when such a data value is provided. In addition to providing an address on the system bus 106, the DAC 102-104 also provides its unique bus master number on the system bus 106.
MPU 110 is configured to protect designated regions of shared system resources by evaluating access requests from DACs 102-104 that fall within those designated regions. For example, in the embodiment illustrated in
As will be described in more detail below, when a DAC 102-104 issues an access request in an attempt to access a shared system resource that is protected by MPU 110, MPU 110 determines whether the requested access should be allowed or denied based on access permissions codified in a “region descriptor” corresponding to the shared system resource, along with knowledge of the state of any semaphore that may be associated with the shared system resource. The region descriptors are stored in region descriptor registers (e.g., registers 602, 604,
In an embodiment, the MPU 110 potentially alters the default access permissions codified in a region descriptor based on the semaphore signals. More particularly, the MPU 110 obtains knowledge of the state of a semaphore that is associated with a particular region descriptor (e.g., the semaphore identified in the region descriptor) through semaphore signals that are provided on hardware connections 130 between the semaphores module 108 and the MPU 110. As will be described in more detail below, the MPU 110 includes circuitry that potentially alters default access permissions stored in region descriptor registers (e.g., registers 602, 604,
The hardware connections 130 are distinct from the system bus 106 and the peripheral busses 124, 126, and are configured to convey the states of the various semaphores (e.g., the contents of the semaphore registers) on a real-time basis. More particularly, the states of each of the semaphores managed by semaphores module 108 are output, via connections 130, to MPU 110. As will be described in more detail later, an access evaluation circuit (e.g., access evaluation logic 610, 612,
As mentioned previously, peripheral modules 120, 122 may be considered to be shared system resources with access protections provided by MPU 110. More particularly, in an embodiment, one or more peripheral modules 120, 122 are operatively connected to peripheral bus 124, which provides a bus protocol that enables DACs 102-104 to access the programming models and/or various registers of peripherals modules 120, 122. Peripheral modules 120, 122 may include, for example, any one or more peripherals selected from a group that includes, but is not limited to, cyclic-redundancy-check (CRC) calculation modules, checksum calculation modules, serial peripheral interfaces (SPIs), universal asynchronous receiver/transmitters (UARTs), counters, timers, memory controllers, display controllers (e.g., liquid crystal display (LCD) controllers), user interface controllers (e.g., keypad, touchscreen, and/or pointer controllers), interrupt controllers, and power-on reset generators to name a few. Electronic system 100 may include various other peripherals, as well.
It is to be understood that the system 100 of
Semaphore registers 202-204 each function as a finite state machine, and the value stored within a semaphore register 202-204 at any given time reflects the current state of the semaphore. More particularly, the value stored within a semaphore register 202-204 reflects which DAC, if any, currently has a lock on the semaphore. In a particular embodiment, each semaphore register 202-204 implements a 2-bit, 3-state machine designed to allow either of two DACs (e.g., either of two CPUs) to lock any given semaphore. In other embodiments, each semaphore register 202-204 may implement a y-bit, z-state machine, where y is greater than 2, and z is greater than 3. In such embodiments, a semaphore state machine may be designed to allow any one of more than two DACs to lock a semaphore (e.g., any one of the N DACs 102-104,
The semaphores module 200 is a memory-mapped module, which includes an interface to peripheral bus 226 (e.g., peripheral bus 126,
As discussed above, according to an embodiment, each semaphore register (e.g., each of registers 202-204,
Upon system startup or reset, state machine 300 is in an “idle” or “unlocked” state 302. For example, state machine 300 may be in the idle state 302 when a value of “00” is stored in the corresponding semaphore register (e.g., register 202,
The state machine 300 remains in the DAC 1 LOCK state 304 or the DAC 2 LOCK state 306 until DAC 1 or DAC 2, respectively, attempts to write an unlock value (e.g., “00”) into the semaphore register. While in the DAC 1 LOCK state 304 or the DAC 2 LOCK state 306 (i.e., when DAC 1 or DAC 2 has the semaphore locked), the semaphores module 200 (
The above description pertains to an embodiment in which either of two DACs may lock a semaphore, and those of skill in the art would understand, based on the description herein, how to modify the above-described embodiment to apply to a system in which more than two DACs may lock a semaphore. In yet other embodiments, the semaphores module 200 may implement a failed lock write notification to a DAC 102-104 when the DAC 102-104 attempted to write to a semaphore that was already locked by another DAC 102-104. In such an embodiment, each semaphore register 202-204 may implement a y-bit, z-state machine designed to record failed lock attempts and transitions based on gate locking and unlocking.
The semaphore remains in the idle state until a lock attempt is received from a DAC (“DAC y”), in block 404. For example, a lock attempt may involve DAC y attempting to write a lock value (e.g., “01” or “10”) associated with the DAC into the semaphore register. The value may be, for example, the bus master number assigned to DAC y. When the lock attempt is received, the semaphores module determines whether or not the semaphore currently is unlocked, in block 406. This may involve determining whether the appropriate idle state value (e.g., “00”) currently is stored in the semaphore register, indicating that the semaphore is in the idle state, and thus unlocked.
When a determination is made that the semaphore is not currently unlocked, the semaphores module may deny the lock attempt, in block 408, by refusing to store the lock value provided by DAC y into the semaphore register. When DAC y subsequently reads the semaphore register, DAC y may compare the read value with the lock value that DAC y attempted to write, and determine that the lock attempt was unsuccessful. In an embodiment, DAC y may then enter a “spin-wait” loop, in which DAC y repeatedly attempts to write its lock value into the semaphore register until, ultimately, DAC y is successful in its write attempt. In an alternate embodiment, after having received a failed lock attempt from DAC y, the semaphores module may provide an unlock indication (e.g., an interrupt notification) to DAC y once the semaphore has been unlocked.
Referring again to block 406, when a determination is made that the semaphore currently is unlocked, the semaphores module writes the lock value into the semaphore register, thus performing a transition from the idle state to a state (e.g., state 304 or 306,
The semaphore remains in the DAC y lock state until a determination is made, in block 412, that an unlock attempt has been received. For example, an unlock attempt may be an attempt by a DAC (e.g., DAC y or some other DAC) to write an idle value (e.g., “00”) into the semaphore register. When an unlock attempt has been received, the semaphores module determines whether the unlock attempt was made by DAC y, in block 414. If not, the unlock attempt is denied, in block 416, by refusing to store the idle value into the semaphore register.
When the semaphores module determines that the unlock attempt was made by DAC y, the semaphores module writes the idle value into the semaphore register, thus performing a transition from the DAC y lock state (e.g., state 304 or 306,
Referring again to
For example, in an embodiment, DAC determination comparators 210 are configured to determine whether the write attempt (or the peripheral bus cycle) was initiated by a valid DAC (i.e., a DAC that is allowed to affect semaphore state transitions). If not, the write attempt is ignored. In addition, write data comparators 212 are configured to determine whether the data that the DAC is attempting to write corresponds to a valid value (e.g., to an idle value (e.g., “00”) or to a valid lock value (e.g., “01” for one DAC and “10” for another DAC)). Again, if it does not, the write attempt is ignored.
The outputs from the DAC determination comparators 210 and the write data comparators 212 are provided to combinational logic 214-216. Combinational logic 214-216 evaluates the comparator outputs in order to create appropriately-configured values for storage in the semaphore registers 202-204. As discussed in detail above, the values in the semaphore registers 202-204 indicate that the semaphore is unlocked, or is locked by one of the DACs. In addition, semaphore signals that represent state information (as indicated by the values stored within the semaphore registers 202-204) are provided over hardware connections 230-232 (e.g., hardware connections 130, 650, 652, 750,
MUX 220 provides a read path for the semaphore registers 202-204. More particularly, in response to a read request from a DAC (e.g., made to validate a write operation), MUX 220 may provide the value contained within a single semaphore register 202-204 to the peripheral bus 226, in an embodiment. In an alternate embodiment, MUX 220 may provide a value that represents a concatenation of a plurality of the semaphore registers 202-204 to the peripheral bus 226. For example, in an embodiment in which each semaphore register 202-204 is a byte (i.e., 8 bits) wide, and the peripheral bus is a word (i.e., 32 bits) wide, MUX 220 may concatenate the values within four semaphore registers 202-204, and may provide the concatenated value to peripheral bus 226. In this manner, a DAC may read the states (i.e., the semaphore register values) of multiple semaphore registers 202-204 with a single read operation. Although, the states of multiple semaphore registers may be read in a single access, only a single semaphore register may be updated via a write operation at a time, in an embodiment.
Interrupt module 222 is configured to provide an interrupt notification (or unlock indication) to a DAC that may have made a failed attempt to lock a semaphore while the semaphore was locked by another DAC. According to an embodiment, interrupt notifications may be enabled or disabled for each DAC. When an interrupt notification is enabled for a DAC, the interrupt module 222 keeps track of failed lock attempts for that DAC, monitors the values within the semaphore registers 202-204, and provides an interrupt to the DAC when a semaphore, which the DAC had failed to lock, becomes unlocked (i.e., transitions to the idle state).
As discussed previously, the MPU (e.g., MPU 110,
In the example embodiment of
Region descriptor 500 also includes a third word 504, which includes default access permission fields 520, 521, 522, 523, 524, 525, 526, 527. Each of the default access permission fields 520-527 may include default access permissions for a single DAC (e.g., one of DACs 102-104,
In contrast with default access permission fields 524-527, default access permission fields (e.g., fields 520-523) may be configured for processor type DACs (e.g., processor cores), and accordingly also may include execute (X) permission fields. Execute permission refers to the ability to read a referenced memory address using an instruction fetch. Processor type DACs may be operated in user mode (UM) and supervisor mode (SM), and accordingly the default access permissions for those DACs may include different UM and SM permissions, as illustrated in
In addition to the above, in an embodiment, a process identifier enable field (PE) may be included in the processor type access permission fields (520-523). When the DyPE bit is set, a process identifier and mask defined in corresponding fields of the region descriptor (e.g., in fields 530, 532 of a fourth word 505 of region descriptor 500) are included in a region hit evaluation. When cleared, the region hit evaluation does not factor in the process identifier or mask.
The fourth word 505 of region descriptor 500 includes a process identifier (PID) field 530, a PID mask field 532, a semaphore identifier (SEM ID) field 534, a semaphore enable (SEME) field 536, and a region descriptor valid (VLD) field 538. In addition, the fourth word 505 may include one or more reserved (or unassigned) bits or fields 540.
PID field 530 may be used to contain a process identifier, which may be included in a determination of whether a current access hits in the region descriptor (e.g., when a DyPE bit is set in a PE field (e.g., in the third word 504). This field is combined with the PID mask in PID mask field 532. The PID mask field 532 provides a masking capability so that multiple process identifiers can be included as part of the region hit determination. For example, the assertion of PID mask bit “i” in PID mask field 532 means that the PID “i” bit in PID field 530 is ignored when comparing the PID/PIDmask combination versus the current PID value driven from the DAC. When enabled, the PID/PIDmask comparison versus the current PID is combined with the start and end address comparisons to determine the region descriptor “hit.”
The semaphore identifier field 534 is used to store an indication of which semaphore (e.g., which of semaphore registers 202-204,
Because region descriptor 500 includes multiple words, and thus updating a region descriptor would involve multiple write operations (e.g., to update a region descriptor in a region descriptor register 602, 604,
As discussed previously, a shared system resource may be defined with a region descriptor (e.g., region descriptor 500,
According to an embodiment, each region descriptor register 602, 604 is comprised of four words, corresponding to the four-word format of the region descriptors (e.g., region descriptor 500,
After the region descriptor registers 602, 604 have been written with region descriptors, DACs may attempt to access shared system resources. More particularly, when a DAC (e.g., one of DACs 102-104,
Access evaluation logic 610, 612 receives the address and bus master number from the system bus 606, and the region descriptors from region descriptor registers 602, 604. In addition, access evaluation logic 610, 612 receives semaphore signals from the semaphores module (e.g., semaphores module 108, 200,
When an access request is present on the system bus 606, access evaluation logic 610, 612 first makes a determination of whether or not the address associated with the access request falls within a region of a shared system resource that is protected by the MPU 600 (i.e., a region that is defined by at least one of the region descriptors in the region descriptor registers 602, 604). In conjunction with this determination, for each region descriptor, access evaluation logic 610, 612 receives a starting address and an ending address from the corresponding region descriptor register 602, 604, and access evaluation logic 610, 612 determines whether the address specified within the access request falls within the range of addresses spanned by the region descriptor (i.e., between the starting and ending addresses).
When the address associated with the access request does fall within the range of addresses spanned by a particular region descriptor stored within a particular region descriptor register 602, 604, access evaluation logic 610, 612 determines whether the DAC that has made the access request is permitted to perform the access into the protected, shared system resource. More particularly, based on the bus master number that the DAC provided on the system bus 606, access evaluation logic 610, 612 determines whether the DAC is permitted to perform an access of a requested access type (e.g., read, write, or execute) specified in the access request.
According to an embodiment, in conjunction with this determination, access evaluation logic 610, 612 produces “effective access permissions” based on the default access permissions specified in the corresponding region descriptor (i.e., stored in the corresponding region descriptor register 602, 604) and the semaphore signals (i.e., signals carried on hardware connections 650, 652) corresponding to a properly-enabled semaphore associated with the region in which the access request address falls (i.e., a semaphore and its associated enable, which are specified in the region descriptor of the corresponding region descriptor register 602, 604). Said another way, access evaluation logic 610, 612 is configured to analyze the received semaphore signals (i.e., signals carried on hardware connections 650, 652) from the semaphores module and the default access permissions from the region descriptor registers 602, 604, and to produce effective access permissions for the DACs by potentially altering the default access permissions based on the semaphore signals. In an embodiment, access evaluation logic 610, 612 includes effective access permissions generation logic 640, 642, which is configured to produce the effective access permissions.
When the semaphore associated with effective access permissions generation logic 700 has not been enabled, as indicated by the SEME flag 735 (e.g., SEME 536,
As implied previously, the semaphore signals conveyed by the semaphores module on the hardware connections 750 may include semaphore signals associated with multiple semaphores. However, only the semaphore signals from a semaphore associated with a particular region descriptor are relevant to the analyses performed by the effective access permissions generation logic 700 for that region descriptor. Accordingly, decoder 702 is configured to receive the semaphore identifier 734 (e.g., semaphore identifier 534,
Based on the selected semaphore signals and an identification of the DAC that is attempting the access (e.g., as indicated by the bus master number on system bus 752), decoder 702 is further configured to produce enable/disable signals on enable lines 740, 742, which signals are provided to the effective permissions logic blocks 704, 706. The effective permissions logic blocks 704, 706 are configured to produce the effective permissions 760, 762 based on the enable/disable signals and the default access permissions 720, 727. According to an embodiment, an effective permissions logic block 704, 706 is associated with the default access permission field (e.g., default access permission fields 520-527,
According to an embodiment, each effective permissions logic block 704, 706 includes logic configured to evaluate each type of default access permissions specified for a particular DAC. Based on the state of the enable/disable signals 740, 742 provided to the logic, the logic is configured either to produce an effective access permission that is the same as a corresponding default access permission (e.g., when the enable/disable signal is in an enable state), or to produce an effective access permission that indicates that the particular type of access is denied (e.g., when the enable/disable signal is in a disable state), despite the corresponding default access permission. Accordingly, even if the default access permissions for a particular DAC specify that a particular access type is permitted, the effective access permission for that access type will specify that the access type is denied for the DAC if the enable/disable signal is in a disable state.
In an embodiment, each effective permissions logic block 704, 706 includes logic (e.g., AND gate 736 or other logic capable of producing an equivalent result) for each access type specified in the default access permissions 720, 727 for a DAC. Each AND gate 736 has a default access permissions input (e.g., input 737) and an enable input (e.g., input 738). The default access permissions input 737 is coupled to receive a signal indicating a default access permission 720 of a particular access type from the region descriptor register. Conversely, the enable input 738 is coupled to receive an enable/disable signal 740, 742. The enable/disable signal 740, 742 is in an enable state when decoder 702 determines that the semaphore signals indicate that the DAC whose access permissions are being evaluated has locked the properly-enabled semaphore associated with the region descriptor. In that case, the AND gate 736 conveys the default access permission 720, 727 of the particular access type that is codified in the default access permissions 720, 727 as the effective access permission 760, 762 for that access type. Conversely, the enable/disable signal 740, 742 is in a disable state when decoder 702 determines that the semaphore signals do not indicate that the DAC whose access permissions are being evaluated has locked the properly-enabled semaphore associated with the region descriptor. In that case, the AND gate 736 does not convey the default access permission 720, 727 of the particular access type that is codified in the default access permissions 720, 727 as the effective access permission 760, 762 for that access type. Instead, the AND gate 736 conveys an effective access permission 760, 762 that indicates that that access type is denied for that DAC.
For example, when the semaphore signals selected by decoder 702 indicate that the properly-enabled semaphore is in an idle state (e.g., state 302,
Conversely, when a DAC has locked the properly-enabled semaphore (i.e., the semaphore is in a locked state, such as one of states 304, 306,
The configurations described herein are intended to avoid situations in which shared system resources are modified in a manner that they become non-coherent (e.g., when multiple DACs make non-serialized writes to a region of a shared system resource). Accordingly, in an embodiment, when a particular DAC has locked a semaphore, the effective access permissions of all other DACs are negated, denying access rights for all access types, as described above. Similarly, when a semaphore is in an idle state, the effective access permissions of all DACs are negated, for all access types. Of primary concern is non-coherent writes to a region of a shared system resource. In some cases, there may be a benefit (or at least little or no harm) in allowing a DAC that has not locked a semaphore to perform read type of accesses (and possibly execute-type of accesses) Accordingly, in an alternate embodiment, only some access types (e.g., write-type of accesses) may be negated by the effective permissions logic blocks 704, 706, whereas other access types are not negated (e.g., the effective permissions for these access types are produced to be the same as the corresponding default access types). Those of skill in the art would understand, based on the description herein, how to modify the described apparatus and method embodiments to contemplate that the system may potentially alter only certain access types specified in the default access permissions, in order to produce the effective access permissions.
As discussed previously, default access permissions may be provided with a one-to-one correspondence between each access type and an indicator of whether or not the access type is allowed or denied (e.g., an enable bit for each access type). Conversely, default access permissions may be encoded. In such a case, the effective permissions logic block corresponding to encoded default access permissions may include additional decoding circuitry (not shown) that is configured to decode encoded access permissions in order to convey a one-to-one correspondence between each access type and an indicator of whether or not the access type is allowed or denied (which indicator is provided to AND gates 736, for example).
The method may begin, in block 802, by storing region descriptor z in a region descriptor register (e.g., one of registers 602, 604,
Once the system has been configured, in block 804, the semaphores module (e.g., semaphores module 108,
At an arbitrary time, in block 806, the MPU may receive an access request from DAC y, and the MPU may determine that the access request specifies an address that falls within the range of addresses encompassed by region descriptor z. The access request also specifies a particular access type (e.g., read, write, or execute).
In block 808, when a semaphore has been enabled for the range of addresses encompassed by region descriptor z (e.g., as indicated in SEME field 536,
In block 810, a determination is made (e.g., by MPU 600) whether the access permissions for DAC y (i.e., the effective access permissions when the semaphore is enabled, or the default access permissions when the semaphore is not enabled) permit the access type specified in the access request from DAC y. If so, then the MPU allows the requested access to occur, in block 812. According to an embodiment, this includes the MPU providing a control signal to a controller associated with the shared system resource, indicating that the requested access is allowed. For example, a bus protocol may provide a control signal (or control vector) that is routed through the MPU, and that defines the validity of each cycle and each transfer. When the MPU determines that the access is allowed (i.e., the effective access permissions permit the requested access), the MPU may provide the control signal to the controller of the shared system resource. Conversely, when the MPU determines (in block 810) that the effective access permissions for DAC y do not permit the access type specified in the access request from DAC y, the MPU may deny (or inhibit) the access, in block 814. According to an embodiment, this includes the MPU providing a control signal to the controller associated with the shared system resource, indicating that the requested access is denied. For example, when the above bus protocol is implemented, the MPU may inhibit the normal transmission of the control signal to the controller of the shared system resource (e.g., the MPU may instead pass an “idle” control signal to the controller). After the requested access has been evaluated and either allowed or denied, the method may then iterate as shown.
The method begins, in block 902, by providing one or more semiconductor substrates. In a system-on-a-chip, in which all of the system components (e.g., the DACs 102-104, system bus 106, semaphores module 108, MPU 110, RAM 112, flash array 114, peripheral modules 120, 122, and peripheral busses 124, 126,
In blocks 904, 906, and 908, multiple DACs (e.g., DACs 102-104), communications busses (e.g., busses 106, 124, 126), one or more slave devices (e.g., RAM 112, flash array 114, peripheral modules 120, 122), a semaphores module (e.g., semaphores module 108, 200,
In block 910, hardware connections (e.g., hardware connections 130, 230-232, 650, 652, 750,
Thus, various embodiments of methods and apparatus for controlling access to shared system resources have been described. An embodiment of an electronic system includes multiple DACs, a semaphores module, and an MPU. Each of the multiple DACs is configured to issue access requests, which request access to a shared system resource. A region descriptor is associated with the shared system resource. The semaphores module is configured to implement a semaphore for the shared system resource, and to produce semaphore signals indicating which one, if any, of the multiple DACs has locked the semaphore for the shared system resource. The MPU is configured to grant or deny the access requests based on the semaphore signals and the region descriptor.
An embodiment of an MPU includes a region descriptor register and access evaluation logic. The region descriptor register is for storing a region descriptor. The region descriptor specifies, for a shared system resource, an address range for the shared system resource and default access permissions for each of multiple data access components. The access evaluation logic is coupled to the region descriptor register. The access evaluation logic is configured to receive the default access permissions and semaphore signals, where the semaphore signals indicate which of multiple DACs, if any, has locked a semaphore associated with the shared system resource. The access evaluation logic is also configured to produce effective access permissions for the multiple DACs by potentially altering the default access permissions based on the semaphore signals, and to determine whether the multiple DACs are permitted to perform requested accesses based on the effective access permissions.
An embodiment of a method for providing access to a shared system resource in an electronic system that includes multiple DACs includes storing a region descriptor for the shared system resource in a region descriptor register. The region descriptor specifies default access permissions for each of the multiple DACs, and the region descriptor identifies a semaphore associated with the shared system resource. The method further includes receiving, through a hardware connection with a semaphores module, semaphore signals that indicate an identity of a DAC, if any, that has locked the semaphore associated with the shared system resource, and producing effective access permissions for the multiple DACs based on the default access permissions and the semaphore signals. When the semaphore signals indicate that a particular DAC has locked the semaphore, the effective access permissions are produced to indicate that access to the shared system resource is denied to other DACs, even when the default access permissions for the other DACs specify that access should be allowed.
While the principles of various embodiments have been described above in connection with specific systems, apparatus, and methods, it is to be clearly understood that this description is made only by way of example and not as a limitation on the scope of the inventive subject matter. Further, the phraseology or terminology employed herein is for the purpose of description and not of limitation.
The foregoing description of specific embodiments reveals the general nature of the various embodiments sufficiently so that others can, by applying current knowledge, readily modify and/or adapt it for various applications without departing from the general concept. Therefore, such adaptations and modifications are within the meaning and range of equivalents of the disclosed embodiments. The inventive subject matter embraces all such alternatives, modifications, equivalents, and variations as fall within the spirit and broad scope of the appended claims.