Precise exit logic for removal of security overlay of instruction space

A circuit generally comprising a first memory, a processor and a logic block is disclosed. The first memory may store (i) a write instruction to store a non-highest security value of at least three security values in a register and (ii) a jump instruction to a second memory. The processor may have a pipeline and may be configured to (i) bootstrap to the first memory while the register stores a highest security value of the security values and (ii) execute the jump instruction following the write instruction. The logic block may be configured to (i) detect the write instruction in an execution stage of the pipeline and (ii) store the non-highest security value in the register in response to detecting the write instruction in a write back stage of the pipeline.

FIELD OF THE INVENTION

The present invention relates to chip data security generally and, more particularly, to a precise exit logic for removal of a security overlay of an instruction space.

BACKGROUND OF THE INVENTION

Digital video Set-Top Box (STB) security is an evolving process. As pirating knowledge increases, the amount of security designed into the STBs is increased to avoid illegal access to descrambling technology. Smart cards are currently being used to provide security for decryption codes. Additional security measures could be introduced to help protect the rest of the box.

SUMMARY OF THE INVENTION

The present invention concerns a circuit generally comprising a first memory, a processor and a logic block. The first memory may store (i) a write instruction to store a non-highest security value of at least three security values in a register and (ii) a jump instruction to a second memory. The processor may have a pipeline and may be configured to (i) bootstrap to the first memory while the register stores a highest security value of the security values and (ii) execute the jump instruction following the write instruction. The logic block may be configured to (i) detect the write instruction in an execution stage of the pipeline and (ii) store the non-highest security value in the register in response to detecting the write instruction in a write back stage of the pipeline.

The objects, features and advantages of the present invention include providing a circuit, method and/or architecture that may provide (i) secured and One-Time Programmable (OTP) memory, (ii) internal boot read-only memory (ROM), (iii) authentication and disable of an Extended Joint Test Action Group (EJTAG) debug interface, (iv) exception vector intercept, and/or (v) cache lockout.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring toFIG. 1, a partial block diagram of a circuit or system100is shown in accordance with a preferred embodiment of the present invention. The partial block diagram is not generally meant to be a completely accurate depiction of the present invention's architecture, but rather a high-level functional overview of the modules that impact the security features. The circuit100generally comprises a circuit or component102, a memory104, a circuit106, and a bus108. An interface110may be provided in the circuit100for general purpose serial communications. An interface112may be provided in the circuit100for debug testing.

The component102may be implemented as a single-chip or a multiple-chip source decoder for digital video and/or audio signals. The component102may provide the interfaces110and112to the circuit100. An interface116may be provided in the component102to couple to the bus108.

The memory104may be implemented as an electrically erasable programmable read-only memory (EEPROM). In one embodiment, the memory104may be implemented as a FLASH memory. The memory104may be coupled to the bus108for access by the component102and the circuit106.

The circuit106may be implemented as an external bus master on the bus108. The bus108may be configured as an external bus (e.g., E-Bus) connecting the component102to the other external circuits and/or external memory blocks. Various standards and protocol may be implemented for the bus108to meet the criteria of a particular application.

The interface110may be implemented as a universal asynchronous receiver/transmitter (UART) interface. The interface112may be implemented as a Joint Test Action Group (JTAG) architecture interface or an EJTAG interface. The JTAG interface is generally defined in The Institute of Electrical and Electronics Engineering (IEEE) Standard 1149.1-2001, titled “IEEE Standard Test Access Port and Boundary-Scan Architecture”, published by the IEEE, New York, N.Y., hereby incorporated by reference in its entirety. The EJTAG interface is generally defined in the “EJTAG Specification”, Revision 2.61, September 2001, published by MIPS Technologies, Inc., Mountain View, Calif., hereby incorporated by reference in its entirety.

The component102generally comprises a circuit or chip120and a memory or chip122. The component102may be configured to perform a source decoding for digital video and/or audio signals. The memory122may be configured as a one-time programmable (OTP) memory module. The OTP memory module122may store security related information for the decoder circuit120. In one embodiment, the decoder circuit120and the OTP memory module122may be fabricated on the same chip.

The decoder circuit120generally comprises a circuit124and a circuit126connected by an internal bus (e.g., I-Bus)128. The circuit124may be implemented as a core processor circuit. The core processor circuit124may be a customer-owned tooling (COT) die or chip. The circuit126may be implemented as an input/output (I/O) circuit. The I/O circuit126may couple the I-Bus128to the OTP memory module122. The I/O circuit126is generally fabricated on the same chip as the core processor circuit124.

The core processor circuit124generally comprises a circuit or block130, a circuit or block132, a circuit or block134, a circuit or block136, a multiplexer138, a multiplexer142, a circuit or block144, a circuit or block146, a circuit or block148, a bus150and a bus152. The circuit130may be implemented as an on-chip memory (OCM) module. The circuit132may be implemented as a processor module. In one embodiment, the processor module132may be a reduced instruction set computer (RISC) processor module. The circuit134may be implemented as an EJTAG enable module. The circuit136may be configured as a security supervisor block or module for the bus152. The circuit144may be implemented as a basic bus and cache controller (BBCC) interface module. The circuit146may be configured as a security flags block or module. The circuit148may be implemented as an external bus controller (EBC) module. The bus150may be implemented as a core bus (e.g., C-Bus). The bus152may be implemented as a system or basic bus (e.g., B-Bus).

The I/O circuit126may include a circuit or block160. The circuit160may be implemented as an enable module for communicating with the OTP memory module122.

The OCM module130generally comprises a memory162, a circuit or block164, a circuit or block166and a circuit or block168. The memory162may be implemented as a read-only memory (ROM) module. In one embodiment, the ROM module162may be configured as a bootstrap ROM or boot ROM for short. The boot ROM module162may store a code163containing instructions. The circuit164may be implemented as a tamper detect module. The circuit166may be implemented as a precise exit logic module. The circuit168may be implemented as an address decode module for decoding addresses on the C-Bus150intended for the boot ROM module162.

The circuit132generally comprises a circuit or block172, a circuit or block174, a circuit or block176and a circuit or block178. The circuit172may be implemented as a UART module. The circuit174may be implemented as a Central Processor Unit (CPU) module. The circuit176may be implemented as a debug port module or a Test Access Port (TAP) module. The debug port module176may be compliant with the EJTAG specification and/or the JTAG specification. Other debug specifications may be implemented to meet the criteria of a particular application. The circuit178may be implemented as a basic bus and cache controller (BBCC) module.

The circuit136generally comprises a circuit170. The circuit170may be configured as a source/target detector module. The source/target detector module170may detect a master (source) and a target address of each transaction of the B-Bus152.

The system100may have multiple security modes or states. In one embodiment, the system100may have a Secure Disabled (SEC_DIS) mode, a Secure Application (SEC_APP) mode and a Secure Privileged (SEC_PRIV) mode. Other states and/or modes may be implemented to meet the criteria of a particular application.

The Secure Disable mode may be active or asserted when code executed from the boot ROM module162determines that security features may not be enforced, and therefore disables the protection. By definition, the CPU module174may no longer be executing from the boot ROM module162while in the Secure Disable mode. The Secure Disabled mode is generally used for a component102that have not yet had the OTP memory module122programmed and may include other uses. The Secure Disable mode may be a lowest of the security modes.

The Secure Application mode is generally asserted or active when the boot ROM determines that security in some form may be useful, including application software (code or firmware) execution. All or some security measures may be active in the Secure Application mode. By definition, the CPU module174may no longer be executing from boot ROM module162while in the Secure Application mode. The Secure Application mode may be an intermediate level security mode.

The Secure Privileged mode may be asserted or active while the CPU module174is still executing from boot ROM module162. While in the Secure Privileged mode, the processor module132may access the OTP memory module122and/or the FLASH memory104. The Secure Privileged mode may be a highest or tightest of the security modes.

Referring toFIG. 2, a flow diagram of a process of transitioning between the security modes is shown. Operations expected to be performed in each security mode are generally indicated within a box labeled with the mode name. Transitions between boxes may represent instruction execution leaving the boot ROM module162. The Secure Privileged mode is generally indicated by box180. The Secure Application mode is generally indicated by box182. The Secure Disable mode is generally indicated by box184.

The process generally begins with the processor module132bootstrapping to the boot ROM module162(e.g., block186). Instructions in the boot ROM module162may then be used to set up a driver for an interface between the I/O circuit126and the OTP memory module122(e.g., block188). If the OTP memory module122has been initialized (e.g., the YES branch of decision block190), one or more instructions stored in the boot ROM module162may be executed to perform a security initialization (e.g., block192). Initialization of the OTP memory122may be determined by a state of a programmable flag stored within the OTP memory122. If initialized, the OTP memory122may be configured for use by the system100. The security initialization may begin to transition the system100from the Secure Privileged mode to the Secure Application mode. A jump instruction stored in the boot ROM module162may then cause the processor module132to execute a jump to a boot vector in the FLASH memory104(e.g., block194). Once the system100has transitioned to the Secure Application mode, an application software may be executed from the FLASH memory104(e.g., block196).

If the OTP memory module122is not initialized (e.g., the NO branch of decision block190), one or more instructions stored in the boot ROM module162may initiate a transition of the system100from the Secure Privileged mode to the Secure Disabled mode. A jump instruction stored in the boot ROM module162may be executed to jump to a boot vector in the FLASH memory104(e.g., block198). Once the system100has transitioned to the Secure Disabled mode, application software may execute from the FLASH memory104(e.g., block200). The application software executed in the Secure Disabled mode may be the same or a different application software as the application software executed in the Secure Application mode.

Before the core processor circuit124is mounted in a package or housing (not shown) with the OTP module122, the core processor circuit124may not be able to function as a secure part. In particular, until the core processor circuit124detects a programmed OTP module122, the core processor circuit124may leave the Secure Privileged mode to the Secure Disabled mode. While in the Secure Disabled mode, decryption operations may be disabled.

In order to implement a feature that (i) a system identification (ID) and (ii) security flags may be programmable only once and not visible outside the packaged part, the component102may use the OTP memory122for storing security related items. The OTP memory122may be designed as a bit-serially-accessed nonvolatile, fused-region memory attached to the I/O circuit126and packaged together with the decoder circuit120die in a multi-chip package. Access to the OTP memory122may be defined according the rules summarized in Table I as follows:

Referring toFIG. 3, a flow diagram of a process for configuring the OTP memory module122in the field is shown. During normal operation of the system100, a service being decrypted may provide a new security upgrade. The security upgrade generally sets security flag registers on-chip that may increase, but not decrease, security settings. The new security register settings may be written into the security flags module146by the application software and may not be effective until a next system reset. The decrypted service may also provide a new code release for storage in the FLASH memory104that contains one or more new security features or objects to be permanently burned into the OTP memory module122. The system100may be reboot (e.g., block210) once the new security features have been loaded into the FLASH memory104.

Upon reboot, the boot ROM code may read a location211(FIG. 1) in the FLASH memory104containing the security flag upgrades. The upgrade flags may then be read from the FLASH memory104(e.g., block218). If the updated flags indicate a same or lower security level than what is already stored in the OTP memory122(e.g., the NO branch of decision block220), the configuration process may be halted. Therefore, attempts to decrease security levels may be ignored. If the upgrade flags stored in the FLASH memory104have higher security settings than what is currently stored in the OTP memory122(e.g., the YES branch of decision block220), the upgrade information or data221(FIG. 1) stored in the FLASH memory104may be copied into the OTP memory122(e.g., block222) by the boot ROM code. Upon a subsequent reboot, the security flag registers within the component102may be set according to the new values read from the OTP memory122. Other flags not modified by the update through the FLASH memory104may be read from the OTP memory122to the appropriate registers.

The boot ROM module122may be accessed upon initialization in a secure component102. The boot ROM module122may be accessible only at boot and may become inaccessible after the boot code has verified a secure installation. In one embodiment, the boot ROM module122may be implemented as 16 KB ROM. Other memory sizes may be implemented to meet a design criteria of a particular application.

The boot ROM module122may reside exclusively in an uncacheable address space of the processor132. The uncacheablity of the boot ROM module122generally facilitates ease of design and integration. There may be no performance implications to the processor132as the boot ROM module122may be designed to provide access times similar to cache accesses, providing a high-performing boot sequence for various computationally intensive activities. In addition, a normal boot vector for an existing CPU module174as well as the bootstrap exception vectors and debug exception vectors may all reside within the uncacheable address space. The contents of the boot ROM module162may not be visible external to the component102, nor determinable from external to the component102. Access to the boot ROM module162may be governed by the rules summarized in Table II as follows:

The component102may have three levels of security for EJTAG. A Baseline level of security may be defined as having no security available and access may be unrestricted at all times when asserted. An Authentication level of security may (i) allow access to all EJTAG features and (ii) the EJTAG debug port module176may undergo a challenge/response-based authentication via the UART port110. Firmware may be used to implement the authentication protocols via the UART interface110. The authentication protocols may be implemented by firmware, code or software. A Locked level of security may disable the EJTAG probe interface112without any authentication. The EJTAG security levels and the associated features may be summarized in Table III as follows:

Referring toFIG. 4, a flow diagram of a process to initialize the EJTAG security flags is shown. The EJTAG functionality may be disabled upon bootstrapping to the boot ROM memory162(e.g., block278) The boot ROM code163may, after setting up the I/O circuit driver for the OTP memory122, read the security flag values for the EJTAG enables from the OTP memory122(e.g., block280). If an EJTAG enable is allowed (e.g., the BASELINE branch of decision block282), the EJTAG probe may be enabled when leaving the boot ROM module162(e.g., block284). If an EJTAG enable is allowed via authentication (e.g., the AUTHENTICATE branch of decision block282), the boot ROM code163may execute a challenge portion of the EJTAG authentication procedure, if programmed in the boot ROM module162(e.g., block286). After the challenge portion, a response portion of the EJTAG authentication procedure may be performed (e.g., block287). Upon successful authentication (e.g., the YES branch of decision block288), the EJTAG probe may be enabled when leaving the boot ROM module162(e.g., block284). Otherwise (e.g., the NO branch of decision block288), the EJTAG probe may be disabled when leaving the boot ROM module162(e.g., block290). If an EJTAG enable is disallowed (e.g., the LOCKED branch of decision block282), the EJTAG probe may be disabled by the boot ROM code (e.g., block290). Disabling the EJTAG probe may include masking an input signal (e.g., TDI)(e.g., block291).

The boot ROM module162may contain a routine at a debug exception vector that may cause a jump-to-self to lock the system100. Assertion of the debug exception vector may be caused by an attempt to gain control of the system100illegitimately.

In order to ensure security in the system100, the exception vectors enabled during the execution of the boot ROM code should be able to detect abuse of normal and debug exception mechanisms and the exception vectors should be thwarted. Therefore breaking into the system100in a privileged state and determining the contents of various sensitive memory locations may be difficult to impossible. All intercepted exceptions should essentially jump-to-self in order to lock the system100from illegal access. Interception of the exceptions is generally a firmware issue using no specialized hardware.

The cache RAMs for the CPU module174may not be accessible functionally via external pins. Software may place the cache memories into a software test mode, allowing the software to read the contents of the cache. However, when the cache is used in security features, the CPU module174is generally under control of the boot ROM firmware and is impervious to outside control. The boot ROM firmware may be written to ensure that the cache contents may not be read later by clearing the caches before exiting the Secure Privileged mode.

The security mode flags in the security flags module146generally indicate the current security levels present in the device. In addition, a register may be provided in the security flags module146that holds a Set Top Box ID for application visibility. The security flag bits may be manipulated using writes to a register in the I-Bus space. A notation of “Write X only” generally indicates that an attempt to write a value other than that X may be ignored.

Referring toFIGS. 5A-D, block diagrams of several example registers are shown. A register inFIG. 5Amay be referred to as a Security Resource Control (SRC) register292. In one embodiment, the SRC register292may be located at an I-Bus128address of 0xBE060000 (hexadecimal). The SRC register292generally contains the register bits that control operations of the security modules in the component102. Several security flags within the SRC register292may be implemented as four-bit values. The four-bit values may prevent over-clocking or power supply manipulations from allowing the less secure states to be entered without software control. The least secure state (meaning the software has more rights) may be a single value of many possible values. All other states may be “more” secure.

The SRC register292generally comprises a flag294, a flag300, a flag302, a flag306and a flag308. The flags294and302may be reserved (R) flags. The flag300may operate as an EJTAG Disable (EDIS) flag. The flag306may operate as a Debug (DGB) flag. The flag308may operate as a Security mode (SEC) flag.

While the flag SEC is set to 8'hAA, the component102may be set to the Secure Disabled mode. While the flag SEC is set to 8'h55, the component102may be set to the Secure Privileged mode. While the flag SEC is set to anything else, the component102may be set to the Secure Application mode.

For ease of understanding, the value of 8'hAA may be referred to as “SEC_DIS”, 8'h55 may be referred to as “SEC_PRIV” and all other values may be referred to as “SEC_APP”, unless a particular value is specified precisely. The boot ROM firmware may modify the flag SEC bits to disable all secure resource protection. Modifying the flag SEC bits may disable all on-chip security. The boot ROM firmware may modify the flag SEC bits to indicate that the boot ROM firmware has completed execution. Completing execution from the boot ROM module162generally disables all future attempts to access the boot ROM module162. Any future accesses to the boot ROM module162address space may be mapped to the B-Bus152and FLASH memory104. A summary of access by the various sources on the B-Bus152based upon the flag SEC bits may be shown in Table IV as follows:

The values of SEC[7:0] and the associated security mode definitions, are generally shown in Table V as follows:

The flag DGB is generally a single read-only bit. The flag DGB may be used by the boot ROM code to determine if an access to the debug exception vector within the boot ROM module162should be handled. Attempts to write to the flag DGB are generally unsuccessful. Access to the flag DGB may be summarized in Table VI as follows:

The flag EDIS may be implemented as a four-bit value. The meaning of the flag EDIS[3:0] is generally summarized below in Table VII as follows:

TABLE VIIEDIS[3:0]Definition4′hAEJTAG Probe EnabledAll othersEJTAG Probe Disabled
For ease of understanding, the value of 4'hA may be referred to as “EJ_EN” and all others as “EJ_DIS”, unless a particular value is specified precisely. The boot ROM firmware may modify the flag EDIS bits to EJ_EN in order to enable all of the EJTAG functionality. Application software may modify the flag EDIS bits to increase EJTAG security (e.g., disable EJTAG functionality) but may not be able to clear the flag EDIS. Reset values for the flag EDIS may be summarized in Table VIII as follows:

TABLE VIIIDGBEDIS[3:0] Rest to:0EJ_DIS (e.g., 4′hF)1EJ_EN
Access to the flag EDIS may be summarized in Table IX as follows:

The fields R may be tied to the logical zero value. The fields R are generally read as zero and may not be writable. The application software should write the R bits to logical zero to preserve functionality in future revisions of the hardware.

Referring toFIG. 5B, a block diagram of a vendor register310is shown. The vendor register310generally comprises a flag312and a flag316. The vendor register310may be located at an address of 0xBE060004 (hexadecimal) in the B-Bus152address space. Each bit of the flags312and316may be set to the logical zero value at reset. Therefore, a default vendor register310may contain the value 0x0fffffff (hexadecimal). The flag316may contain reserved (R) bits.

The flag312may be implemented as a single-bit EJTAG Authentication (EA) bit. While the EA bit has the logical zero value, the EJTAG Authentication may be disabled. While the EA bit has the logical one value, the EJTAG Authentication may be enabled. The boot ROM firmware may modify the EA bit to enable or disable the EJTAG authentication. The application software may not write the EA bit. The EA bit may have a reset value of 1'b0. Access to the flag EA may be summarized in Table X as follows:

Referring toFIG. 5C, a block diagram of a Set Top Box ID High register322is shown. The Set Top Box ID High register322generally comprises a 32-bit field324. The field324may be designated as a high word (e.g., STBID_HIGH) of an overall set top box identification value. The Set Top Box ID High register322generally has an address of 0xBE060008 (hexadecimal) in the B-Bus152address space. Access to the Set Top Box ID High register322may be granted to the CPU module174while executing from the boot ROM module162, read-only to the CPU module174while not executing from the boot ROM module162, and no access for non-CPU masters while in the Secure Privileged mode. The field STBID_HIGH may have a reset value of 0xffffffff (hexadecimal). The field STBID_HIGH may be set at boot by the CPU module174by reading the STB ID value from the OTP memory122. No other master, including the CPU module174while in Secure Application or Secure Disabled mode, may write to the STBID_HIGH field.

Referring toFIG. 5D, a block diagram of a Set Top Box ID LOW register326is shown. The Set Top Box ID LOW register326generally comprises a 32-bit field328. The field328may be designated as a high word (e.g., STBID_LOW) of the overall set top box identification value. The Set Top Box ID LOW register326generally has an address of 0xBE06000C (hexadecimal) in the B-Bus152address space. Access to the Set Top Box ID LOW register326may be granted to the CPU module174while executing from the boot ROM module162, read-only to the CPU module174while not executing from the boot ROM module162, and no access for non-CPU masters while in the Secure Privileged mode. The field STBID_LOW may have a reset value of 0xffffffff (hexadecimal). The field STBID_LOW may be set at boot by the CPU module174by reading the STB ID value from the OTP memory122. No other master, including the CPU module174while in Secure Application or Secure Disabled mode, may write to the STBID_LOW field.

In order to prevent other modules from having to decode the various four-bit values for each multi-bit security flag, the security flags module146may decode the values into a set of signals that indicate the security levels. Two signals may be decoded for the SEC[7:0] field. A signal (e.g., SECURE_PRIVILEGED_MODE) may indicate that the Secure Privileged mode is active. A signal (e.g., SECURE_APPLICATION_MODE) may indicate that the Secure Application mode is active. In the event that the component102is in Secure Disabled mode, both of the signals SECURE_PRIVILEGED_MODE and SECURE_APPLICATION_MODE may be inactive.

Referring toFIG. 6, a block diagram of a portion of a scan chain330is shown. The scan chain330may be routed through the security related registers of the security flag module146, and/or in other modules. An example single bit of a security related register may be indicated by a flip-flop332. The scan chain330may be disabled for the flip-flop322while a signal (e.g., SCAN_ENABLE) is deasserted. A flip-flop334may provide temporary storage of a value (e.g., DOUT) loaded from the flip-flop332into the scan chain330, or from an upstream flip-flop (not shown) in the scan chain330, based upon a signal (e.g., SHIFT). The flip-flop334may generate and transmit a data signal (e.g., TDO) to a downstream flip-flop (not shown) in the scan chain330. A multiplexer338may allow the scan chain330to (i) bypass or disable the flip-flop332and (ii) sample the flip-flop332.

During a wafer probe test, the component102to be placed into scan mode and the signal SCAN_ENABLE may be asserted by the security flags module146. During package testing of the secure part102, the scan chain330may bypass the flip-flop332by holding the signal SCAN_ENABLE inactive in the logical zero state. While the signal SCAN_ENABLE is in the logical one state, the contents of the flip-flop332(e.g., the signal DOUT) may be visible on the scan chain330.

Logic (e.g., the X input of the flip-flop332may be a Set input or a Clear input) may be implemented to tie off the values to the security related registers (e.g., flip-flop332) to predetermined secure states while a signal (e.g., SCAN_MODE) is active. The logic may prohibit registers upstream from controlling, via functional paths and a scan “evaluate” phase, the contents of the security related registers. The logic may set the values SRC[SEC]=SEC_APP and SRC[EDIS]=EJ_DIS if the scan mode is indicated and a functional clock (e.g., LOAD) is toggled. The logic may prohibit use of the scan chain330indirectly from placing the part102into a looser security state, such as the Secure Disabled state.

Functional testing of the security related registers is generally not feasible prior to programming the OTP memory122. In the Secure Disabled mode, the values that the security related registers may take is limited. However, once the OTP memory122has been programmed, the CPU module174may leave the Secure Privileged mode and transition to the Secure Application mode instead. In the Secure Application mode, the security related bits may be much more testable. Some of the security registers may not read/write in the Secure Application mode, but if the part102is functioning correctly, the functional test software should be able to read back the contents that were programmed into the OTP memory122from the security registers. A unique test program per chip may be used to read the security values from the OTP memory122. The unique test programs may be performed at the customer's location at which the parts102have been programmed. Verification of the security register may not be complex as the unique test program that configures the part102may already know the unique chip information (e.g., chip ID, etc.) in order to test the design correctly. The on-site testing may filter the remaining test escapes leaving the component manufacturer as a result of the secure scan chain.

The OCM module130is generally responsible for providing both the boot ROM module162and the precise boot ROM execution termination logic module166tightly coupled to a pipeline of the CPU module174, to prevent windows of insecure operation. The OCM module130may sit exclusively in the uncacheable address range of the C-Bus150. Although the RISC processor132memory map may allow the OCM module130to sit in a cacheable address range as well, the choice of the uncacheable address range generally eliminates a possibility that the secure code may be cached.

The OCM module130generally sits on the CPU system C-Bus150. The C-Bus150may support the OCM module150via a simple interface. An address may be brought out of the processor132that the decode module168may decode and claim before the address reaches the CPU caches and the B-Bus152. Although running uncached, accesses to the boot ROM module162memory space may be very fast as the OCM module130may have an access time allowing zero wait-state accesses, duplicating the performance of cached code.

Following a hardware reset, the CPU module174may boot from the boot ROM module162. The boot operation is generally controlled by the SRC[SEC] bits. If the SRC[SEC] bits are equivalent to SEC_PRIV, the CPU module174may boot from and execute from the internal boot ROM module162. If the SRC[SEC] bits are equivalent to SEC_DIS, the CPU module174may boot from and/or execute from the FLASH memory104. If the SRC [SEC] bits are equivalent to SEC_APP, the CPU module174may execute from the FLASH memory104.

Software163running from the boot ROM module162may have privileged status as a Secure Privileged mode device, with full access to the entire address map of the component102. Control of the privileged access is generally provided by the security supervisor hardware module136. The security supervisor module136may identify if an instruction being executed is from the boot ROM module162, and if so, enable read and write access to all protected address regions.

The exit from the boot ROM module162may be precise. With only a single secure memory region, such as the boot ROM module162, clearing one or more bits enabling execution from the boot ROM module162and executing a jump to the normal boot vector in the FLASH memory104may be difficult. Furthermore, the pipeline in the CPU module174, write buffering, and indeterminate latencies on the B-Bus and I-Bus interfaces may increase the difficulty of a proper exit in executing from the boot ROM module162. As such, the OCM module130may implement a very precise method that determines when the bits have been set to switch the system from Secure Privileged mode (e.g., executing from the boot ROM module162) to the Secure Application mode. The precise boot ROM exit logic module166may mimic the CPU pipeline to determine when to exit. A store to the SRC register292with an intent to change the SEC[7:0] field from SEC_PRIV to SEC_APP or SEC_DIS, and to configure any other bits for operation outside the boot ROM module162, may be observed by the precise boot ROM exit logic module166. The precise boot ROM exit logic module166may indicate that the bits in the SRC register292may be changed at a precise time, in accordance with the CPU pipeline, to the bits in the SRC register292actually sitting on the I-Bus.

Referring toFIG. 7, a block diagram illustrating the firmware sequence to exit the boot ROM module162is shown. The precise boot ROM exit logic module166may register the updated SRC value at the end of the X2 execute stage (e.g., at time340) of the CPU module pipeline341. The updated SRC values may be sent to an I-Bus addressable register (e.g., in the security supervisor module136) and written at the end of the WB write-back stage of the CPU instruction (e.g., at time342). The write at time342to the SRC register292may also pass through a write buffer (not shown) and may eventually occur again while in the Secure Application mode or Secure Disabled mode. The second write to the SRC register292may have a possible, but unlikely and harmless effect of decreasing security levels that an application software had just set at normal boot time (e.g., the application software may have raised a security state from what was programmed in the OTP memory122.) Since the OTP memory122may be the ultimate source of controlled security, the second write to the SRC register292is generally a don't-care scenario. Other security related registers may be updated in other ways to help ensure precise exit from the boot ROM module162.

The tamper protection module164may detect that the CPU module174has vectored from the boot ROM module162while still executing in the Secure Privileged mode. Vectoring from the boot ROM module162prematurely may potentially be caused by over-clocking or power-glitching the part102. Over-clocking or power-glitching the part102may cause the CPU module174to fetch an instruction that is not targeted to the on-chip boot ROM module162while in Secure Privileged mode. In the event that the tamper detect module164detects an improper vector, the tamper detect module164may immediately transition the part102into the Secure Application mode by changing the value in the flag SEC.

The OCM module130may be surrounded by a scan wrapper131to be used for scan test of the memory within. The precise exit logic module166may be part of the disable-able scan chain(s)173of the core processor circuit144. Other test architectures for the OCM module130may be implemented to meet the criteria of a particular application.

Referring toFIG. 8, a table of a security supervisor module136protection process is shown. For the purposes of the table shown inFIG. 8, “Other” masters encompass an E-Bus108external master (e.g., master circuit106) and the CPU module174, where appropriate. Notes in the table may be as follows:

(1) The registers that may be written as defined in the security flags module146.

(2) Registers typically may only be written, if at all, to indicate a higher security level.

The security supervisor module136may be a conceptual block that implements a fixed protection scheme for the address map of the component102. The source/target detector module170within the security supervisor module136generally uses the following information to determine the source of an access that is being supervised: (i) identification of the master that is accessing the B-Bus152and (ii) the absolute address of the current instruction executing in the CPU module174. The master may be one of the CPU core module174or the E-Bus controller module148.

The security supervisor module136may use the address to which the transaction is going to determine the destination of the access and then rule on the validity of the transaction based on the table shown inFIG. 8. In order to ensure security, the comparison addresses should be fixed such that there may be no programmability of the address comparison values. Because of the CPU pipeline, there is generally a latency between the CPU module174fetching an instruction from an address and the execution of that instruction. To ensure synchronization of both indications that the CPU module174is initiating a B-Bus152transaction and is executing from a specific area in memory, a few non-operation instructions may be placed after a load instruction or a store instruction that falls near a jump or branch that may cause the CPU module174to leave the privileged area. Otherwise, the load or store indications might fail to be synchronized. However, as long as the boot ROM module162is exited properly, the lack of synchronization should not be a concern. However, branching outside of the boot ROM module162while still in Security Privileged mode may present a security issue.

When the source/target detector module170detects an improper transaction on the B-Bus152, the security supervisor module136may subvert the B-Bus152transaction. For a read transaction, a receive command signal from the source to the target may be forced inactive by the security supervisor module136through the multiplexer138to prevent the target from seeing the read. A ready signal from the target to the source (or master) may be forced active by the security supervisor module136through the multiplexer142to prevent the master from hanging waiting for a response. The security supervisor module136generally returns a predetermined value (e.g., 0x00000000) as data to the master. The master may consider the predetermined data as a valid return.

For a write transaction, the transmit command signal from the master to the target may be forced inactive by the security supervisor module136through the multiplexer138to prevent the target from seeing the write. A ready signal from the target to the master may be forced active by the security supervisor module136through the multiplexer142to prevent the master from hanging waiting for a response. The security supervisor module136may not provide known data on a write, as the write may not take place.

The CPU module174may reset to a state in which interrupts are disabled. The CPU reset state may be implemented so that interrupts may not take control of the component102before the boot ROM code163has a chance to set one or more predetermined bits to handle the interrupts.

The enable circuit160may prevent use of the interface between the I/O circuit126and the OTP memory122while in the Secure Application mode. Disabling the interface may be done at a top level of the decoder circuit120. A buffer (not shown) within the enable circuit160driving a clock into the OTP memory122may have the data input driven to a logical one such that the clock may never be driven. A similar data input to a buffer (not shown) in the enable circuit160driving a write protect (WP) pin on the OTP memory122may also be driven to a logical one such that the write protect pin is never driven.

Disabling the interface to the OTP memory122may be performed if the signal SCAN_MODE is active (e.g., the signal that may be active the entire time that scan testing is performed). Disabling the interface to the OTP memory122may prevent the use of a boundary scan chain from getting access to the contents of the OTP memory122.

Referring toFIG. 9, a block diagram of an example mechanism374by which pins may be protected is shown. The mechanism or circuit374generally comprises a multiplexer376, a logic gate378, a buffer380, a logic gate382, a multiplexer384, a logic gate386and a buffer388. The buffer380may be connected to and drive a bonding pad or pin390. The buffer388may be connected to and drive a bonding pad or pin392.

A signal (e.g., S1) may be received by the gate378. The signals SECURE_APPLICATION_MODE and SCAN_MODE may the logically OR'd together by the logic gate382. The signals generated by the multiplexer376and the OR gate382may be logically OR'd by the logic gate378, amplified by the buffer380, and driven onto the pad390. Therefore, while either or both of the signals SECURE_APPLICATION_MODE and SCAN_MODE are in the logical one state, the pad390may be forced to and held at the logical one state.

A signal (e.g., S2) may be logically OR'd with the signal SCAN_MODE. A result signal generated by the OR gate386may be amplified by the buffer388and driven onto the pad392. Therefore, while the signal SCAN_MODE is in the logical one state, the pad392may be forced to and held at the logical one state.

The signals S1and S2may also be isolated from the boundary scan chain to prevent illegal control of the OTP memory122. The signals S1and S2may be removed from the chain by tying off the inputs such that the boundary scan chain may not influence the respective values. Furthermore, the boundary scan chain may bypass the chain contribution of the signals S1and S2to the next pins downstream such that the boundary scan chain is unbroken. Pins for the external bus controller block148to the FLASH memory104may be on the boundary scan chain. Having the external bus controller block148to FLASH memory104interface in the boundary scan chain generally allows for proper testing of the manufactured component102. As a result of the JTAG boundary scan chain:

1. Product testing generally uses two different sets of JTAG vectors.

2. Two different Boundary Scan Debug Layer (BSDL) files may be generated.

3. The Multi-Chip Module (MCM) pins in the JTAG boundary scan chain may not longer be tristated once bonded.

4. Leakage measurements of the MCM pins may no longer be possible.

5. Levels on the MCM pins may no longer be measurable.

Several features of the present invention may include, but are not limited to: (i) a security flags block that may implement registers containing on-chip values used to control the security operation, (ii) an on-chip memory module that may provide a ROM for a one-time-only boot execution, (iii) a security supervisor that may govern access to various on-chip secure resources based on legal source/destination combinations, (iv) an EJTAG enable module to control when the EJTAG Probe may be enabled, (v) a CPU with interrupts immediately disabled on reset and (vi) a special core processor circuit boundary scan chain.

The various signals of the present invention are generally “on” (e.g., a digital HIGH, or 1) or “off” (e.g., a digital LOW, or 0). However, the particular polarities of the on (e.g., asserted) and off (e.g., de-asserted) states of the signals may be adjusted (e.g., reversed) accordingly to meet the design criteria of a particular implementation. Additionally, inverters may be added to change a particular polarity of the signals. As used herein, the term “simultaneously” is meant to describe events that share some common time period but the term is not meant to be limited to events that begin at the same point in time, end at the same point in time, or have the same duration.