Safe debugging

Abstract

The disclosed embodiments provide systems and methods that can be used as part of or in combination with autonomous navigation, autonomous driving, or driver assistance technology functions. Driver assistance technology, as opposed to fully autonomous driving, can refer to any suitable technology used to assist a driver in navigating or controlling their vehicle. In various embodiments, the system may include one or more cameras and associated processors that can be mounted in the vehicle, monitoring the vehicle's environment. In further embodiments, additional types of sensors may be mounted in the vehicle and used in the autonomous navigation and / or driver assistance system. These systems and methods may include using a shared cache shared by a group of processing units to improve the analysis of images captured by one or more cameras.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 63 / 091,586, filed on October 14, 2020, the contents of which are incorporated herein by reference in their entirety. Background Technology

[0003] Advanced Driver Assistance Systems (ADAS) and Autonomous Vehicle (AV) systems use cameras and other sensors, along with object classifiers, to detect specific objects in the environment of vehicles traveling on roads. Object classifiers are designed to detect predefined objects and are used within ADAS and AV systems, allowing for vehicle control or driver alerts based on the type or location of detected objects. As ADAS and AV systems evolve towards fully autonomous operation, protecting the data generated by these systems will be beneficial. Summary of the Invention

[0004] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar parts. While several illustrative embodiments have been described herein, modifications, adaptations, and other implementations are possible. For example, components illustrated in the drawings may be replaced, added, or modified, and the illustrative methods described herein may be modified by replacing, reordering, removing, or adding steps to the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples.

[0005] The disclosed embodiments provide systems and methods that can be used as part of or in combination with autonomous navigation, autonomous driving, or driver assistance technology functions. Driver assistance technology, as opposed to fully autonomous driving, can refer to any suitable technology used to assist a driver in navigating or controlling their vehicle. Examples of driver assistance technologies include forward collision warning (FCW), lane departure warning (LDW), traffic sign recognition (TSR), and other driver assistance technologies. In various embodiments, the system may include one, two, or more cameras and associated processors that can be mounted in the vehicle to monitor the vehicle's environment. In further embodiments, additional types of sensors may be mounted in the vehicle and used in the autonomous navigation and / or driver assistance system. In some examples of the currently disclosed subject matter, the system may provide techniques for processing images of the environment prior to the vehicle navigating a road, wherein this processing includes training a neural network or deep learning algorithm to estimate the vehicle's future path based on the images. In yet another further example of the currently disclosed subject matter, the system may provide techniques for using a trained neural network to process images of the environment to estimate the vehicle's future path prior to the vehicle navigating a road.

[0006] Systems and methods as described in the claims and specification are provided. Any combination of any subject matter of any claim may be provided. Any combination of any method or method steps disclosed in any drawing or specification may be provided. Any combination of any unit, device, or component disclosed in any drawing or specification may be provided. Non-limiting examples of such units include aggregation units, image processors, etc. Attached Figure Description

[0007] The subject matter considered to be the subject matter is specifically pointed out and explicitly claimed for protection at the end of the specification. However, when combined with the appendix... Figure 1 When reading this material, the organization and operation of the subject matter, as well as its purpose, features, and advantages, can be best understood by referring to the following specific embodiments, wherein:

[0008] Figure 1 It is a block diagram representation of a system conforming to the disclosed embodiments;

[0009] Figure 2A It is a schematic side view representation of an exemplary vehicle including a system conforming to the disclosed embodiments;

[0010] Figure 2B It conforms to the disclosed embodiments. Figure 2A A top-view illustration of the vehicles and systems shown.

[0011] Figure 2CThis is a top view representation of another embodiment of a vehicle that includes a system conforming to the disclosed embodiments;

[0012] Figure 2D This is a top view representation of yet another embodiment of a vehicle that includes a system conforming to the disclosed embodiments;

[0013] Figure 2E This is a schematic representation of an exemplary vehicle control system conforming to the disclosed embodiments;

[0014] Figure 3 It is a graphical representation of the user interface conforming to the disclosed embodiments;

[0015] Figure 4 The diagram illustrates an example of an integrated circuit;

[0016] Figure 5 The diagram illustrates an example of a path between an integrated circuit and a non-cacheable data unit;

[0017] Figure 6 The diagram illustrates an example of the path between an integrated circuit and a cacheable data unit;

[0018] Figure 7 The diagram illustrates an example integrated circuit and a path for writing back to the data cell;

[0019] Figure 8 The diagram illustrates an example integrated circuit and a path to a write-through data cell;

[0020] Figure 9 The diagram illustrates an example integrated circuit and a path to a data cell with write-through disabled;

[0021] Figure 10 The diagram illustrates an example of the method;

[0022] Figure 11 The diagram illustrates an example of the method;

[0023] Figure 12 The diagram illustrates an example of the method;

[0024] Figure 13 The diagram illustrates an example of a debugging method;

[0025] Figure 14 The diagram illustrates an example of an integrated circuit;

[0026] Figure 15 The diagram illustrates an example of an integrated circuit;

[0027] Figure 16 The diagram illustrates an example of an integrated circuit;

[0028] Figure 17The diagram illustrates an example of an integrated circuit; and

[0029] Figure 18 The figure shows an example of an integrated circuit. Detailed Implementation

[0030] Numerous specific details are set forth in the following detailed description to provide a comprehensive understanding of the subject matter. However, those skilled in the art will understand that the subject matter can be practiced without these specific details. In other respects, well-known methods, processes, and components have not been described in detail so as not to obscure the subject matter.

[0031] The subject matter considered to be the subject matter is specifically pointed out and explicitly claimed for protection at the end of the specification. However, when combined with the appendix... Figure 1 When reading this article, the organization and operation of the subject matter, as well as its purpose, features, and advantages, can be best understood by referring to the following specific implementation methods.

[0032] It will be understood that, for the sake of simplicity and clarity, the elements shown in the figures are not necessarily drawn to scale. For example, for clarity, the dimensions of some elements may be enlarged relative to others. Furthermore, where deemed appropriate, reference numerals may be repeated between figures to indicate corresponding or similar elements.

[0033] Because the embodiments illustrated in this subject matter can be implemented in most cases using electronic components and circuits known to those skilled in the art, details will not be explained in a greater scope than is deemed necessary above in order to understand and comprehend the basic concepts of this subject matter and to avoid confusion or deviation from its teachings.

[0034] Any references to the methods in this specification, with necessary modifications, shall be adapted to systems capable of performing the methods, and with necessary modifications, to non-transitory computer-readable media storing instructions that, once executed by a computer, would cause the methods to be performed.

[0035] Any references to the system and any other components in this specification, modified as necessary, shall apply to methods executable by a memory device, and shall be modified as necessary to a non-transitory computer-readable medium storing instructions executable by a memory device. For example, a method or method steps executable by an image processor may be provided, or a method or method steps executable by an image processor may be provided.

[0036] Any references to non-transitory computer-readable media in this specification, with necessary modifications, shall apply to systems capable of executing instructions stored in non-transitory computer-readable media, and with necessary modifications, to methods executable by a computer that reads instructions stored in non-transitory computer-readable media.

[0037] Any combination of any module or element listed in any of the accompanying drawings, any part of the specification, or any claim may be provided. In particular, any combination of any claimed features may be provided.

[0038] Before discussing these examples in detail (such as examples of processing images of the environment in front of a vehicle traveling on a road to train a neural network or deep learning algorithm to estimate the future path of the vehicle based on the image; or using a trained neural network to process images of the environment in front of a vehicle traveling on a road to estimate the future path of the vehicle), a description is provided of various possible implementations and configurations of a vehicle-mountable system that can be used to perform and implement the methods of the examples according to the currently disclosed subject matter. In some embodiments, the various examples of the system can be mounted in a vehicle and can operate while the vehicle is in motion. In some embodiments, the system can implement the methods of the examples according to the currently disclosed subject matter.

[0039] However, it will be understood that embodiments of this disclosure are not limited to scenarios where suspicious upright object indications are caused by high-grade roads. Suspicious upright object indications can be associated with a variety of other situations and can be generated from other types of image data or from data that is not image-based or is not uniquely image-based.

[0040] Now for reference Figure 1 This is a block diagram representation of a system conforming to the disclosed embodiments. Depending on the requirements of a particular implementation, system 100 may include various components. In some examples, system 100 may include a processing unit 110, an image acquisition unit 120, and one or more memory units 140, 150. Processing unit 110 may include one or more processing devices. In some embodiments, processing unit 110 may include an application processor 180, an image processor 190, or any other suitable processing device. Similarly, depending on the requirements of a particular application, image acquisition unit 120 may include any number of image acquisition devices and components. In some embodiments, image acquisition unit 120 may include one or more image capture devices (e.g., cameras), such as image capture device 122, image capture device 124, and image capture device 126. In some embodiments, system 100 may also include a data interface 128 communicatively connecting processing unit 110 to image acquisition device 120. For example, data interface 128 may include any one or more wired or wireless links for transmitting image data acquired by image acquisition device 120 to processing unit 110.

[0041] Both application processor 180 and image processor 190 can include various types of processing devices. For example, either or both of application processor 180 and image processor 190 can include one or more microprocessors, preprocessors (such as image preprocessors), graphics processors, central processing units (CPUs), supporting circuitry, digital signal processors, integrated circuits, memory, or any other type of device suitable for running applications and for image processing and analysis. In some embodiments, application processor 180 or image processor 190 can include any type of single-core or multi-core processor, mobile device microcontroller, central processing unit, or other type of processor. Various processing devices can be used, including, for example, those available from manufacturers (e.g., The processor obtained by (etc.), and various processing devices can include various architectures (e.g., x86 processors, etc.). wait).

[0042] In some embodiments, application processor 180 or image processor 190 may include components that can be accessed from... Any of the obtained EyeQ series processor chips. These processor designs each include multiple processing units with local memory and instruction sets. Such processors may include video input for receiving image data from multiple image sensors, and may also include video output capabilities. In one example, It uses 90 nanometer-micron technology operating at 332 MHz. The architecture features a dual-float, hyper-threaded 32-bit RISC CPU. (core), five visual computing engines (VCE), and three vector microcode processors Denali features a 64-bit mobile DDR controller, 128-bit internal acoustic interconnect, dual 16-bit video input and 18-bit video output controllers, a 16-channel DMA, and several peripherals. The MIPS34K CPU manages five VCEs, three VMP™, DMA, a second MIPS34K CPU, multi-channel DMA, and other peripherals. (Five VCEs, three...) The MIPS34K CPU can perform the intensive visual computations required for versatile bundled applications. In another example, as a third-generation processor and... Six times stronger It can be used in the published examples. In yet another example, (The fourth-generation processor) can be used in the published examples.

[0043] Although Figure 1The processing unit 110 is depicted as including two separate processing devices, but more or fewer processing devices may be used. For example, in some examples, a single processing device may be used to perform the tasks of the application processor 180 and the image processor 190. In other embodiments, these tasks may be performed by more than two processing devices.

[0044] Processing unit 110 may include various types of devices. For example, processing unit 110 may include various devices such as controllers, image preprocessors, central processing units (CPUs), support circuitry, digital signal processors, integrated circuits, memory, or any other type of device for image processing and analysis. The image preprocessor may include a video processor for capturing, digitizing, and processing images from an image sensor. The CPU may include any number of microcontrollers or microprocessors. Support circuitry may be any number of circuits generally known in the art, including caches, power supplies, clocks, and input / output circuitry. Memory may store software that controls the operation of the system when executed by the processor. Memory may include databases and image processing software, such as trained systems (e.g., neural networks). Memory may include any number of random access memory (RAM), read-only memory (ROM), flash memory, disk drives, optical storage, removable storage, and other types of storage. In one instance, the memory may be separate from processing unit 110. In another instance, the memory may be integrated into processing unit 110.

[0045] Each memory unit 140, 150 may include software instructions that, when executed by a processor (e.g., application processor 180 or image processor 190), can control the operation of various aspects of system 100. These memory units may include various database and image processing software. The memory units may include random access memory, read-only memory, flash memory, disk drives, optical storage, magnetic tape storage, removable storage, or any other type of storage. In some examples, memory units 140, 150 may be separate from application processor 180 or image processor 190. In other embodiments, these memory units may be integrated into application processor 180 or image processor 190.

[0046] In some embodiments, the system may include a position sensor 130. The position sensor 130 may include any type of device adapted to determine the location associated with at least one component of the system 100. In some embodiments, the position sensor 130 may include a Global Positioning System (GPS) receiver. Such a receiver can determine the user's location and speed by processing signals broadcast by GPS satellites. Location information from the position sensor 130 may be available to either the application processor 180 or the image processor 190.

[0047] In some embodiments, system 100 may be operatively connectable to various systems, devices, and units on a vehicle (in which system 100 may be installed), and system 100 may communicate with the vehicle's systems via any suitable interface (e.g., a communication bus). Examples of vehicle systems with which system 100 may cooperate include throttling systems, braking systems, and steering systems.

[0048] In some embodiments, the system 100 may include a user interface 170. The user interface 170 may include any device adapted to provide information to one or more users of the system 100 or to receive input from one or more users of the system 100, such as a touchscreen, microphone, keyboard, pointing device, trackwheel, camera, knob, button, etc. Information may be provided to the user by the system 100 through the user interface 170.

[0049] In some embodiments, the system 100 may include a map database 160. The map database 160 may include any type of database for storing digital map data. In some examples, the map database 160 may include data relating to the location of various items (including roads, water features, geographic features, points of interest, etc.) in a reference coordinate system. The map database 160 may not only store the locations of such items but also descriptors associated with those items, such as names and other information associated with any of the stored features. For example, the database may include the location and type of known obstacles, information relating to the topography of roads or the rank of certain points along roads, and so on. In some embodiments, the map database 160 may be physically located along with other components of the system 100. Alternatively or additionally, the map database 160 or portions thereof may be remotely located relative to other components of the system 100 (e.g., processing unit 110). In such remote embodiments, information from the map database 160 may be downloaded via a wired or wireless data connection to a network (e.g., via a cellular network or the Internet).

[0050] Image capture devices 122, 124, and 126 may each include any type of device suitable for capturing at least one image from the environment. Furthermore, any number of image capture devices can be used to acquire images for input to an image processor. Some examples of the currently disclosed subject matter may include or can be implemented using only a single image capture device, while other examples may include or can be implemented using two, three, four, or more image capture devices. References will be made below. Figures 2B-2E Image capture devices 122, 124 and 126 are further described.

[0051] As will be appreciated, system 100 may include other types of sensors or may be operatively associated with other types of sensors, such as acoustic sensors, RF sensors (e.g., radar transceivers), lidar sensors, or other sensors. Such sensors may be used independently of image acquisition device 120 or may be used in conjunction with image acquisition device 120. For example, data from a radar system (not shown) may be used to verify processed information received from processed images acquired by image acquisition device 120, such as to filter out certain false positives obtained from processed images acquired by image acquisition device 120. Data from the radar system may also be combined with or otherwise complement image data from image acquisition device 120, or combined with a processed variant or derivative of image data from image acquisition device 120.

[0052] System 100 or its various components can be incorporated into a variety of different platforms. In some embodiments, system 100 can be included on vehicle 200, such as... Figure 2A As shown. For example, as mentioned above relative to... Figure 1 The vehicle 200 may be equipped with the processing unit 110 and any other components of the system 100. While in some embodiments the vehicle 200 may be equipped with only a single image capture device (e.g., a camera), in other embodiments multiple image capture devices (such as a combination of...) may be used. Figures 2B-2E (Those embodiments discussed). For example, such as Figure 2A As shown, either the image capture device 122 or 124 of the vehicle 200 may be part of an ADAS (Advanced Driver Assistance System) imaging suite.

[0053] The image capture device included on the vehicle 200, as part of the image acquisition unit 120, can be positioned at any suitable location. In some embodiments, such as Figures 2A-2E and Figure 3 As shown, the image capture device 122 can be located in the area near the rearview mirror. This location provides a line of sight similar to that of the driver of the vehicle 200, which can help determine what is visible and invisible to the driver.

[0054] Other locations may also be used for the image capture device of the image acquisition unit 120. For example, the image capture device 124 may be located on or within the bumper of the vehicle 200. Such locations may be particularly suitable for image capture devices with a wide field of view. The line of sight of the image capture device located on the bumper may be different from the driver's line of sight. Image capture devices (e.g., image capture devices 122, 124, and 126) may also be located in other locations. For example, the image capture device may be located on or within one or both side mirrors of the vehicle 200, on the roof of the vehicle 200, on the hood of the vehicle 200, on the trunk of the vehicle 200, on the side of the vehicle 200, mounted on any window of the vehicle 200, positioned behind or in front of any window of the vehicle 200, and mounted in or near a vehicle light at the front or rear of the vehicle 200, or in other locations. Image capture unit 120, or one of a plurality of image capture devices used in image capture unit 120, may have a different field of view (FOV) than that of the driver of the vehicle, and may not always see the same objects. In one example, the FOV of image capture unit 120 may extend beyond the typical driver's FOV, and thus can image objects outside the driver's FOV. In yet another example, the FOV of image capture unit 120 is a portion of the driver's FOV. In some embodiments, the FOV of image capture unit 120 corresponds to a sector covering the road area in front of the vehicle and possibly also the surrounding environment of that road.

[0055] In addition to the image capture equipment, vehicle 200 may also include various other components of system 100. For example, processing unit 110 may be included on vehicle 200, integrated with or separate from the vehicle's engine control unit (ECU). Vehicle 200 may also be equipped with position sensor 130 (such as a GPS receiver) and may also include map database 160 and memory units 140 and 150.

[0056] Figure 2A It is a schematic side view representation of a vehicle imaging system based on an example of the currently published subject. Figure 2B yes Figure 2A The example shown is illustrated in a top view. Figure 2BAs illustrated, the disclosed examples may include system 100 within vehicle 200. System 100 may include a first image capture device 122, a second image capture device 124, and a processing unit 110. The first image capture device 122 is positioned near or close to the rearview mirror of vehicle 200, and the second image capture device 124 is positioned on or within the bumper area of ​​vehicle 200 (e.g., one of bumper areas 210).

[0057] like Figure 2C As illustrated, both image capture devices 122 and 124 can be positioned near the rearview mirror of vehicle 200 or close to the driver. Additionally, although in Figure 2B and Figure 2C Two image capture devices 122 and 124 are shown, but it should be understood that other embodiments may include more than two image capture devices. For example, in Figure 2D In the illustrated embodiment, the system 100 of the vehicle 200 includes a first image capture device 122, a second image capture device 124, and a third image capture device 126.

[0058] like Figure 2D As illustrated, image capture devices 122, 124, and 126 can be positioned near the rearview mirror of vehicle 200 or close to the driver's seat. The disclosed examples are not limited to any particular number and configuration of image capture devices, and the image capture devices can be positioned within or on vehicle 200 at any suitable location. It should also be understood that the disclosed embodiments are not limited to a particular type of vehicle 200, but are applicable to all types of vehicles, including cars, trucks, trailers, motorcycles, bicycles, self-balancing transport equipment, and other types of vehicles.

[0059] The first image capture device 122 may include any suitable type of image capture device. Image capture device 122 may include an optical axis. In one example, image capture device 122 may include an Aptina M9V024WVGA sensor with a global shutter. In another example, a rolling shutter sensor may be used. Image acquisition unit 120 and any image capture device implemented as part of image acquisition unit 120 may have any desired image resolution. For example, image capture device 122 may provide a resolution of 1280x960 pixels and may include a rolling shutter. As used herein, pixels may include image elements acquired by a camera or may include processed image elements.

[0060] Image acquisition unit 120 and any image capture device implemented as part of image acquisition unit 120 may include various optical elements. In some embodiments, one or more lenses may be included, such as those providing the desired focal length and field of view for image acquisition unit 120. These lenses can be used in any image capture device implemented as part of image acquisition unit 120. In some examples, image capture device implemented as part of image acquisition unit 120 may include or be associated with any optical element, such as a 6mm lens or a 12mm lens. In some examples, image capture device 122 may be configured to capture images with a desired and known field of view.

[0061] The first image capture device 122 may have a scan rate associated with the acquisition of each image scan line in a first series of image scan lines. The scan rate may refer to the rate at which the image sensor is able to acquire image data associated with each pixel included in a particular scan line.

[0062] Figure 2E This is a graphical representation of a vehicle control system based on an example of a currently published topic. For example... Figure 2E As indicated, vehicle 200 may include a throttle system 220, a braking system 230, and a steering system 240. System 100 may provide inputs (e.g., control signals) to one or more of the throttle system 220, braking system 230, and steering system 240 via one or more data links (e.g., any one or more wired or wireless links for transmitting data). For example, based on analysis of images acquired by image capture devices 122, 124, or 126, system 100 may provide control signals to one or more of the throttle system 220, braking system 230, and steering system 240 to navigate vehicle 200 (e.g., by inducing acceleration, steering, lane changes, etc.). Furthermore, system 100 may receive inputs indicating the operating status of vehicle 200 (e.g., speed, whether vehicle 200 is braking or steering, etc.) from one or more of the throttle system 220, braking system 230, and steering system 240.

[0063] Figure 3 This is a schematic representation of the user interface 170 conforming to the disclosed embodiments. For example... Figure 3As shown, vehicle 200 may also include a user interface 170 for interacting with the driver or passengers of vehicle 200. User interface 170 may include one or more sensors positioned near rearview mirror 310 or console display 320. For example, user interface 170 in a vehicle application may include touchscreen display 320, knob 330, button 340, and microphone 350. The driver or passengers of vehicle 200 may also interact with system 100 using handles (e.g., turn signal handles located on or near the steering column of vehicle 200), buttons (e.g., on the steering wheel of vehicle 200), etc. In some embodiments, microphone 350 may be positioned adjacent to rearview mirror 310. Similarly, in some embodiments, image capture device 122 may be located near rearview mirror 310. In some embodiments, user interface 170 may also include one or more speakers 360 (e.g., speakers of a vehicle audio system). For example, system 100 may provide various notifications (e.g., alarms) via speaker 360.

[0064] As those skilled in the art who benefit from this disclosure will appreciate, many variations or modifications can be made to the disclosed embodiments. For example, not all components are necessary for the operation of system 100. Furthermore, any component can be located in any suitable part of system 100, and components can be rearranged into various configurations while providing the functionality of the disclosed embodiments. Thus, the foregoing configurations are examples, and regardless of the configurations discussed above, system 100 can provide a wide range of functions to analyze the environment surrounding vehicle 200 and, in response to that analysis, navigate or otherwise control or operate vehicle 200. Navigation, control, or operation of vehicle 200 may include enabling or disabling (directly or via an intermediate controller such as the controller mentioned above) various features, components, devices, modes, systems, or subsystems associated with vehicle 200. Navigation, control, or operation may alternatively or additionally include, for example, interaction with users, drivers, passengers, pedestrians, or other vehicles or other users, whether located inside or outside vehicle 200, by providing visual, audio, tactile, or other sensory alerts or indications.

[0065] As discussed in further detail below and consistent with the various disclosed embodiments, system 100 can provide various functions related to autonomous driving, semi-autonomous driving, or driver assistance technologies. For example, system 100 can analyze image data, location data (e.g., GPS location information), map data, speed data, or data from sensors included in vehicle 200. System 100 can collect data from, for example, image acquisition unit 120, position sensor 130, and other sensors for analysis. Further, system 100 can analyze the collected data to determine whether vehicle 200 should take a certain action, and subsequently automatically take the determined action without human intervention. It will be appreciated that in some cases, the actions automatically taken by the vehicle are under human supervision, and the ability to intervene, adjust, suspend, or override machine actions is enabled in certain situations or at all times. For example, when vehicle 200 is navigating without human intervention, system 100 can automatically control the braking, acceleration, or steering of vehicle 200 (e.g., by sending control signals to one or more of throttle system 220, braking system 230, and steering system 240). Furthermore, system 100 can analyze the collected data and, based on the analysis of the collected data, issue warnings, instructions, recommendations, alerts, or commands to the driver, passengers, users, or other persons inside or outside the vehicle (or to other vehicles). Additional details regarding various embodiments provided by system 100 are provided below. Any numerical values ​​described in the specification are non-limiting examples of numerical values. Other values ​​may be provided or used. Unless otherwise specified, these values ​​may be lower than or may be higher than those mentioned in this application.

[0066] Access control mechanism in cache coherence integrated circuits

[0067] Integrated circuits (including those included in AV or ADAS systems) can perform a variety of tasks efficiently and safely. Such integrated circuits may include multiple processing units and multiple hardware accelerators. Processing units can be configured to execute multiple processing threads and selectively share data among processing units or hardware accelerators.

[0068] Processing units can use shared caches. Some hardware accelerators within a hardware accelerator can also use shared caches to share portions of program and data that need to be processed by more than one hardware accelerator (e.g., two, three, or more). Furthermore, portions of the same data can be used by both the hardware accelerators and the processing unit; therefore, the contents of any shared cache stored in any of the shared caches can be accessed by both the hardware accelerators and the processing unit. This sharing allows the processing unit to execute different parts of the program while sharing data related to or generated by the program's execution.

[0069] Integrated circuits may include multiple communication modules that can receive data units from various peripheral devices or other initiators. A subset of data units may be updated versions of older data units cached in a shared cache. Cache coherence needs to be maintained, for example, to prevent processing units from using irrelevant cached data units. Cache coherence should be maintained while upholding access control rules that restrict access by various initiators or processing units to various ranges of memory space.

[0070] Access control rules can be provided to each initiator or at each destination, and these rules are subsequently enforced by each initiator or at each destination. When there are many initiators and many processing units, the configuration and updating of access control rules can become complex and time-consuming. Therefore, it is necessary to maintain cache coherence while controlling access in an efficient and secure manner. Integrated circuit devices, methods, and non-transitory computer-readable media capable of implementing access control and maintaining cache integrity can be provided.

[0071] Figure 4 The diagram illustrates an example of integrated circuit 400. Integrated circuit 400 may be included in processing unit 110. This integrated circuit may be a system-on-a-chip (SOC). Integrated circuit 400 may include:

[0072] a. A group of processing units (such as a central processing unit (CPU) 491).

[0073] b. Shared cache, such as the CPU's Level 2 (L2) cache (labeled "CPU's L2 cache") 492. Other levels of shared cache memory may be used.

[0074] c. First Access Control Unit (ACU_1) 493.

[0075] d. Second Access Control Unit (ACU_2) 473.

[0076] e. Hardware Accelerator (ACC) 481 group.

[0077] f. Additional shared caches, such as the L2 cache of the ACC (labeled as "the L2 cache of the ACC") 482.

[0078] g. Interconnect 450.

[0079] h. Third Access Control Unit (ACU_3) 473.

[0080] i. Volatile memory 470, which may store information or commands, such as, cryptographic keys (“cryptographic keys”) 471, codes of one or more hardware accelerators in the hardware accelerator (“ACC codes”) 472, neural network coefficients (“NN coefficients”) 475, and data 474. The volatile memory may be a DRAM memory cell.

[0081] j. Cipher unit (“Cipher unit 462”).

[0082] k. Communication Module (“Communication”) 461. Different communication modules may be assigned to different communication protocols or to different initiators.

[0083] l. First access control metadata (ACM) 452 (1) that can be accessed by the first ACU 493.

[0084] m. Second ACM 452(2) accessible by second ACU 473.

[0085] n. A third ACM 452(3) accessible by a third ACU 483.

[0086] Each Access Control Metadata (ACM) can define access rights for different initiators, access rights for different access requests (e.g., read, write), and so on. The first, second, and third ACMs can be protected in various ways to prevent tampering (e.g., unauthorized access). In the example, tamper protection measures could include applying access control rules to prevent access to the ACM, where the access control rules could be written during the integrated circuit's boot sequence.

[0087] The hardware accelerator 481 can be a neural network processor, a vector processor, a dedicated image processing core, a programmable array of processing units, and so on. The hardware accelerator can be customized to generate certain types of tasks in a more efficient manner than general-purpose processing units.

[0088] Shared cache memory can be different from Level 2 (L2) cache. While L2 cache is shown, they can be caches of various levels, such as L3 or others. The allocation between processing units or hardware accelerators can be... Figure 4 The allocations shown in the diagrams differ. In various examples, a subset of processing units may share a shared cache, a subset of hardware accelerators may share a shared cache, and this shared cache and additional shared caches may be decoupled from each other; multiple interconnects may exist between or within devices; volatile memory may be different from DRAM memory cells, and multiple volatile memory cells may exist; integrated circuits may include one or more non-volatile memory cells; cryptographic units may be located elsewhere, and multiple cryptographic units may exist, and so on.

[0089] The CPU 491 group, the first ACU 493, and the CPU's L2 cache 492 may be included in the first part 490 of the integrated circuit. The third ACU 483, the ACC 481 group, and the ACC's L2 cache 482 may be included in the second part 480 of the integrated circuit.

[0090] Interconnect 450 may be coupled to first section 490, second section 480, cryptographic unit 462, second ACU 473, and communication module 461. Interconnect 450 may be directly or indirectly coupled to an initiator that initiates an access request. The initiator may include any circuit capable of initiating an access request. Examples of initiators include sensors, processing units, controllers, another integrated circuit, etc. Interconnect may be replaced by one or more circuits that can connect first section 490, second section 480, second ACU 473, communication module 461, and cryptographic unit 462 to each other.

[0091] Any of the communication modules in the communication module can be configured to receive access requests (such as read requests and write requests). For simplicity, the following example refers to a write request for a data unit. It is also assumed that the integrated circuit is configured to manage write requests from initiators that may not belong to a group of processing units. The write request is used to write a data unit to a target address. The target address can be an address within a memory space supported by volatile memory 470.

[0092] Communication module 461 can be configured to send data units to interconnect 450, which in turn sends the data units to a first ACU 493. Communication module 461 can also be configured to send data units to a second ACU 273 if a transaction is marked as non-cacheable. The data unit must pass through the first ACU 493 in the sense that it is upstream of the shared cache (i.e., the CPU's L2 cache 292) before it can be written to the CPU's L2 cache 492. During operation, it is assumed that interconnect 450 will send at least some non-cacheable data units to the second ACU 473 and may send at least some cacheable data units to the first ACU 492 (e.g., under certain conditions).

[0093] The first ACU 493 can be configured to determine at least one destination for a write request. This destination can be volatile memory 470, the CPU's L2 cache 492, or both. Therefore, the first ACU 493 can send only data units to volatile memory 470, only data units to the CPU's L2 cache 492, or both. The first ACU 493 can be configured to determine the destination based on the initiator's access rights and a cache policy.

[0094] In one example, the first ACU 493 may send the data unit to volatile memory 470. The first ACU 493 may send the data unit to volatile memory 470 without sending it to the CPU's L2 cache 493. In another example, when an older version of the data unit is not present in the CPU's L2 cache 492 and the transaction is not marked as write-allocation, the first ACU 493 may send the data unit to volatile memory 470 without sending it to the CPU's L2 cache 493. In yet another example, when an older version of the data unit is not present in the CPU's L2 cache 492 and the transaction is not marked as write-allocation, the first ACU 493 may send the data unit to volatile memory 470 without sending it to the CPU's L2 cache 493, even if the data unit is cacheable.

[0095] Sending cacheable data units to volatile memory 470 may include sending them via bypass path 499. This assumes that there is no expired version of the data unit in the CPU's L2 cache 492 and that the transaction is not marked as a write-allocation. Sending via bypass path 499 may go unnoticed by any processing unit in the processing unit, or may be performed autonomously without intervention from any processing unit in the group. Sending via bypass path may include keeping the data unit unchanged. For example, sending via bypass path may include suppressing or otherwise avoiding tagging the data unit as being sent from a group of processing units. Tagging can be avoided because the data unit does not reach the CPU's L2 cache.

[0096] The first ACU 493 can also be configured to check (e.g., monitor) the CPU's L2 cache 492 to determine whether the CPU's L2 cache 492 stores an older data unit associated with a target address. The check of the CPU's L2 cache 492 can be performed after the data unit is deemed cacheable, or it can be performed before checking whether the data unit is cacheable. When the check of the CPU's L2 cache 492 finds that the shared cache stores an older data unit associated with a target address, the first ACU 492 invalidates the older data unit.

[0097] When it is determined that a shared cache is one of at least one of the destinations where a data unit should be written, the first ACU 493 may assist in writing the data unit to the shared cache (e.g., the CPU's L2 cache 492) (e.g., generating a request to write the data unit to the shared cache). Further in response to this determination, the first ACU 493 may be configured to associate the source of the data unit with a group of processing units to provide the associated data unit, and to participate in sending the associated data unit to a memory unit.

[0098] Because data units are sent from the first portion 490 to the volatile memory 470, the data units can be associated with a group of processing units. This association is part of the configuration of the first ACU 493. Various ACUs of the integrated circuit can be configured to perform this association before sending the data units to the volatile memory.

[0099] The second ACU 473 can be configured to receive associated data units and determine that the associated data units should be written to the volatile memory 470. This determination can be based on access rights of the processing unit group. Further in response to this determination, the second ACU 473 can be configured to assist in writing the data units to the memory units.

[0100] Figure 5 The diagram illustrates an example of the path between integrated circuit 400 and non-cacheable data unit (NCDU) 401. Figure 5 In this process, the interconnect 450 identifies the data unit as a non-cacheable data unit, determines whether to send the data unit to the volatile memory 470, and sends the data unit to the second ACU 473 instead of sending it to the first ACU 493. This may also occur when the data unit is cacheable but an older version of the data unit does not exist in the CPU's L2 cache 492, and when the transaction is not marked as a write-allocation.

[0101] Figure 6 The diagram illustrates an example of the path between integrated circuit 400 and data cells. In Figure 6 In this process, the interconnect 450 determines that the data unit is cacheable, but an older version of the data unit does not exist in the CPU's L2 cache 492, and the transaction is not marked as a write-allocation. The first ACU 493 can be configured to send NCDU 401 without associating the source of the data unit with the group of processing units.

[0102] Figure 7 The diagram illustrates an example of the path between integrated circuit 400 and write-back data unit (WBDU) 402. As described herein, this data unit may be referred to as a write-back data unit because the caching strategy applied by the shared cache relative to this data unit is a write-back caching strategy. Figure 7 In this process, the first ACU493 receives WBDU 402, identifies WBDU 402 as a write-back data unit, and writes the WBDU only to the cache memory without sending it to the volatile memory 470.

[0103] When a write-through policy is applied, data units may be allocated to volatile memory, but may or may not be allocated to the shared cache. The write allocation indicator can be set or reset to indicate whether write allocation is enabled or disabled. When write allocation is disabled, the shared cache is not updated. Conversely, when write allocation is enabled, the shared cache is updated. In both cases, the associated data unit is sent to volatile memory 470.

[0104] Figure 8 The diagram illustrates an example of the path between integrated circuit 400 and write-through enabled data unit (WTEDU) 403. As described herein, this data unit may be referred to as write-through enabled because the cache policy is write-through and write allocation is enabled. Figure 8In the process, WTEDU 403 arrives at the first ACU 493. Upon receiving WTEDU 403, the first ACU 493 detects that the data unit is a write-through enabled data unit, sends WTEDU 403 to the shared cache, generates an associated write-through enabled data unit A-WTEDU 403', and sends A-WTEDU 403' to volatile memory 470. A-WTEDU 403' is associated with a group of processing units.

[0105] Figure 9 The diagram illustrates an example path between the example integrated circuit 400 and the write-through disabled data unit (WTEDU) 404. As described herein, this data unit may be referred to as write-through disabled because the cache policy is write-through, and write allocation is disabled. Figure 9 In the process, WTDDU 404 arrives at the first ACU 493. Upon receiving WTDDU 404, the first ACU 493 detects that the data unit is a write-through disabled data unit, sends WTDDU 404 to the shared cache, generates an associated write-through disabled data unit A-WTDDU 404', and sends A-WTDDU 404' to volatile memory 470. A-WTDDU 403' is associated with a group of processing units.

[0106] The third access control unit (ACU_3) 483 can be configured to control (e.g., according to access rules) data unit sharing between the CPU's L2 cache 492 and the ACC's L2 cache. Processing units may control the operating system and may be more susceptible to tampering (e.g., unauthorized intrusion attempts). To reduce or minimize the risks associated with tampering, at least some of the data units stored in the ACC's L2 cache should not be sent to the CPU's L2 cache 492. Some data in the ACC's L2 cache may be shared with the CPU's L2 cache 492, particularly when one or more processing units and one or more accelerators are involved in certain tasks.

[0107] The third access control unit ACU_3 483 can be configured to receive requests to share data between the L2 cache of the ACC and the L2 cache of the CPU. The third access control unit ACU_3 483 can also be configured to determine whether to share data based on the access rights of the processing unit group.

[0108] Figure 10An example of method 500 is illustrated. Method 500 can provide updates to a shared cache shared by a group of processing units. Method 500 may begin at step 510: initializing the integrated circuit. This may include: loading or determining access rules during the boot sequence. Step 510 may include: configuring an access rule data structure that can be accessed by a first access request unit during the boot process of the security unit of the integrated circuit. The access rule data structure may store access restrictions associated with a first plurality of address ranges. Address ranges not included in the first plurality of address ranges may be accessed by the initiator. This provides a compact access rule data structure that can focus on a small number of memory ranges with access restrictions.

[0109] Step 510 may be followed by step 520: receiving a write request from an initiator outside the group of processing units (i.e., not belonging to the group of processing units) for writing the data unit to the target address. Step 520 may be followed by step 522: sending the data unit to the first access control unit located upstream of the shared cache via the interconnect.

[0110] Step 522 may be followed by step 524: The first access control unit determines that the shared cache stores an older data unit associated with the target address. This determination may be based on the contents of the shared cache and may involve checking the shared cache. Step 524 may be followed by step 526: In response to determining that the shared cache stores an older data unit, the older data unit associated with the target address is invalidated.

[0111] Step 522 may also be followed by step 528: the first access control unit determines at least one destination for the write request from among the shared cache and memory units, wherein the memory units are different from the shared cache. This determination is based on the initiator's access rights and on a caching policy. Examples of caching policies may include write-back, write-through with enabled write allocation, write-through with disabled write allocation, or another caching policy.

[0112] Step 528 may include: determining, by a first access control unit, that the at least one destination is a shared cache. In one example, this determination may occur when the cache policy is a write-back policy. In another example, the determination may occur when the cache policy is a write-through policy and the write allocation attribute associated with the data unit has a first value indicating that write allocation is enabled. In yet another example, the determination may occur when the cache policy is a write-through policy and the write allocation attribute associated with the data unit has a second value indicating that write allocation is disabled.

[0113] When it is determined that a data unit should be written to a shared cache, step 528 is followed by step 530: Write the data unit to the shared cache. Alternatively, when it is determined that a data unit should be written to a memory unit, step 528 is followed by steps 532 and 534. It should be noted that step 528 may be followed by both steps 530 and 532. Step 532 may include: Associating the source of the data unit with a group of processing units used to provide the associated data unit.

[0114] Step 532 may be followed by step 534: sending the associated data unit to the memory unit. Step 534 may be followed by step 536: the associated data unit is received by the second access control unit located upstream of the memory unit.

[0115] Step 536 may be followed by step 538: the second access control unit determines that the associated data unit should be written to the memory unit. This determination may be based on the access rights of the processing unit group. When the determination indicates that the associated data unit should be written to the memory unit, step 538 may be followed by step 540: the associated data unit is written to the memory unit. Alternatively, when the determination indicates that the associated data unit should not be written to the memory unit, the associated data unit is not written to the memory unit.

[0116] Method 500 may include step 560: receiving a request by a third access control unit to share data between the shared cache of the integrated circuit and an additional shared cache. The additional shared cache is shared by a group of hardware accelerators different from the processing unit. Step 560 may further include: determining the data to be shared based on the access rights of the processing unit's group.

[0117] Figure 11 An example of method 501 is illustrated. Method 501 differs from method 500 by including additional steps 521, 521', 522', 535, 536', 538', and 540' and excluding step 522. Step 521 follows step 520 and includes: sending a data unit to the interconnect. Step 521 may be followed by step 521': determining by the interconnect whether the data unit is cacheable. In response to determining that the data unit is cacheable, step 521' may be followed by step 522': sending the data unit from the interconnect to a first access control unit located upstream of the shared cache.

[0118] Step 522' can be followed by step 524: The first access control unit determines that the shared cache stores an older data unit associated with the target address. This determination may be based on the contents of the shared cache and may involve checking the shared cache. Step 524 can be followed by step 526: In response to determining that the shared cache stores an older data unit, the older data unit associated with the target address is invalidated.

[0119] Step 522' may be followed by step 528: The first access control unit determines at least one destination for the write request from among the shared cache and memory units, wherein the memory unit is different from the shared cache. This determination is based on the initiator's access rights and on a caching policy. Step 528 may include: the first access control unit determining that the at least one destination is the shared cache. When it is determined that the data unit will be written to the shared cache, step 528 is followed by step 530: the data unit is written to the shared cache. Alternatively, when it is determined that the data unit will be written to the memory unit, step 528 is followed by steps 532-540.

[0120] In response to determining that the data unit is cacheable, step 521' may be followed by step 535: sending the data unit to the memory unit. Step 535 may be followed by step 536': the data unit is received by the second access control unit located upstream of the memory unit. Step 536' may be followed by step 538': the second access control unit determines that the data unit should be written to the memory unit. This determination is based on the access rights of the processing unit group. When it is determined that the data unit should be written to the memory unit, step 538' may be followed by step 540': the data unit is written to the memory unit.

[0121] Figure 12 The figure illustrates an example of method 502. Method 502 differs from method 500 by including additional steps 527, 527', 536', 538', and 540'. Step 527 follows step 522, where step 522 includes sending a data unit to a first access control unit via an interconnect. Step 527 may include determining by the first access control unit whether the data unit is cacheable. In response to determining that the data unit is cacheable, step 527 may be followed by step 527': sending the data unit from the first access control unit to a memory unit. Step 527' may be followed by step 536': receiving the data unit by a second access control unit located upstream of the memory unit. Step 536' may be followed by step 538': determining by the second access control unit that the data unit should be written to the memory unit. This determination is based on the access rights of the processing unit group. When it is determined that the data unit should be written to the memory unit, step 538' may be followed by step 540': writing the data unit to the memory unit.

[0122] In response to determining that the data unit is cacheable, step 527 may be followed by step 528: the first access control unit determines at least one destination for the write request from among the shared cache and memory units, wherein the memory unit is different from the shared cache. This determination is based on the initiator's access rights and on a caching policy. Step 528 may include: the first access control unit determining that the at least one destination is the shared cache. When it is determined that the data unit will be written to the shared cache, step 528 is followed by step 530: the data unit is written to the shared cache. Alternatively, when it is determined that the data unit will be written to the memory unit, step 528 is followed by steps 532-540.

[0123] Secure debugging using multi-factor authentication

[0124] Integrated circuits can be debugged during their development phase and after they are manufactured. A commonly used debugging standard is JTAG. JTAG is named after the Joint Test Action Group that wrote it, and it is an industry standard for verifying designs and testing printed circuit boards post-manufacturing (www.wikipedia.org). JTAG implements a standard for on-chip instrumentation in electronic design automation (EDA) as a complementary tool to digital simulation. It specifies a dedicated debug port implementing a serial communication interface for low-overhead access without direct external access to the system address and data buses. The interface connects to the On-Chip Test Access Port (TAP), which implements a stateful protocol for accessing a set of test registers that present the chip's logic levels and device capabilities for each section.

[0125] The Joint Test Action Group, formed in 1985, developed a method for verifying and testing designs after manufacturing. In 1990, the Institute of Electrical and Electronics Engineers (IEEE) incorporated the results of this work into IEEE Standard 1149.1-1991, entitled "Standard Test and Access Port and Boundary Scan Architecture".

[0126] The dedicated debug port of the JTAG standard, or any other debug port used for debugging integrated circuits, can be used to tamper with (e.g., unauthorized access) integrated circuits. To reduce or prevent this tampering, there is a growing need for secure debugging methods, and therefore a growing need for integrated circuits with secure debugging capabilities. Secure debugging reduces or prevents unauthorized access by hackers to data or commands stored in integrated circuits. Secure debugging also prevents authorized debugging processes from gaining access to data or commands that should not be exposed during the debugging process.

[0127] An integrated circuit may be provided, which may include a debug port and a security element. The security element may be configured to determine whether debugging is enabled. If the security element suspects that a debug request is inappropriate, such as as a result of unauthorized access to the integrated circuit, the security element may determine not to enable debugging. For example, as an adjunct to control (e.g., prevention) of debugging activation, the security element may be configured to control the timing of debugging. In the example, debugging execution may be prevented until all programs except the one to be debugged have terminated. The security element may perform one or more additional measures to reduce or prevent unnecessary exposure of data or commands during debugging.

[0128] Figure 13 The figure illustrates an example of debugging method 600. Debugging method 600 may begin at step 610. Step 610 may be triggered during the boot process of the integrated circuit, following the boot process, after a predefined time interval has been reached, in response to the integrated circuit experiencing a predetermined failure defined as requiring debugging, in response to the occurrence of an event, or in response to another trigger. Events that may trigger step 610 may include events requiring debugging, such as predefined behavior of the integrated circuit, predefined behavior of cells affected by the integrated circuit, software updates of cells affected by the integrated circuit, replacement of cells in a vehicle, or other triggering events.

[0129] Step 610 may be followed by step 612: The security unit of the integrated circuit determines whether to enable debugging of the processing unit. This determination may be based on a specific debugging request, or it may be based on other parameters unrelated to a specific debugging request. For example, the determination may be based on whether debugging can be performed within one or more predefined time periods, where the time period may include the lifetime of the integrated circuit; the expiration of a certain time period; or after the subsequent reset and booting of the integrated circuit. This determination may be performed during the boot process of the security unit, during which the security circuit retrieves boot instructions from the non-volatile memory cells of the integrated circuit. The boot process may include: decrypting encrypted instructions or data stored in the memory cells of the integrated circuit using the unique identifier of the processing unit.

[0130] Step 612 may include generating a debug determination indicator. In this example, the debug determination indicator may be unchangeable except by determination step 612. The debug determination indicator may be accessible by a security unit or by an access control unit.

[0131] In response to determining that debugging will not be performed, step 612 may be followed by step 613: prevent debugging. Alternatively, in response to determining that debugging steps will be performed, step 612 may be followed by step 614: receive a debugging request through the debug port of the integrated circuit.

[0132] Step 614 may be followed by step 618: Verifying the debug request. This verification may involve: performing an authentication process or sending a challenge and waiting for a valid response, receiving a password and verifying its validity, etc. This verification may include: using the public or private key of the integrated circuit to verify that the debug requester who generated the debug request knows the unique identifier of the processing unit, etc. Step 618 may be performed by an access control unit, which may be a security unit, may be different from a security unit, may be included in a security unit, or may not be included in a security unit.

[0133] If step 618 determines that the debug request is not valid, step 618 may be followed by a return to step 614 to await any subsequent debug requests. An invalid debug request may also trigger an alarm or any other response, such as preventing any debugging from occurring within a predefined time period following the execution of step 618.

[0134] In response to step 618 determining that the debugging steps are valid, step 618 may be followed by step 620: preparing at least a portion of the integrated circuit for debugging. This at least portion of the integrated circuit may include processing units, memory resources accessible by the processing units, other processing units, or memory resources accessible by other processing units. Step 620 may include: verifying that any programs executed by processing units not related to debugging are terminated before debugging. In the example, a program is considered related to the debugging process when its execution is required for completion. Step 620 may include: erasing any sensitive information from any memory cells accessible by debugging. Sensitive information may be defined as information marked as sensitive or information that should not be exposed during debugging. Examples of sensitive information may include: cryptographic keys, neural network coefficients, filter coefficients, and code. Another example of sensitive information may include... Figure 14 The contents of the volatile memory 470 in the memory. Step 620 may also include replacing the unencrypted (e.g., decrypted) data unit or command with the corresponding encrypted data unit or command.

[0135] Step 620 can be followed by step 624: Allow debugging. Once step 624 has been successfully completed, step 624 can be followed by step 628: Perform debugging. Performing debugging may include: participating in the debugging process. Debugging can be performed under the control of the tester or another initiator, and the integrated circuit may participate in the debugging. Participating in debugging may include: executing debugging commands, transmitting debugging-related data or commands, executing debugging-related programs, etc. Step 628 may be controlled by the initiator.

[0136] Figure 14 , Figure 15 and Figure 16 The figure shows integrated circuit 401. Figure 17The figure shows integrated circuit 402. Integrated circuits 401 and 402 can be configured to perform method 500. Figure 18 The figure illustrates integrated circuit 403. Integrated circuit 403 can be configured to perform method 600. Integrated circuits 401, 402, and 403 can be included in processing unit 110.

[0137] Integrated circuit 401 may include:

[0138] a. Debugging interfaces, such as JTAG interface 441.

[0139] b. Verification unit 441' is used to verify debug requests.

[0140] c. Debug access control unit (“Debug ACU”) 484.

[0141] d. Non-volatile memory cell 469 (see Figure 14 , Figure 15 and Figure 16 The non-volatile memory cells within ).

[0142] e. A group of processing units (such as a central processing unit (CPU) 491).

[0143] f. Shared cache, such as the CPU's Level 2 (L2) cache (labeled "CPU's L2 cache") 492. Other levels of shared cache memory may be used.

[0144] g. First Access Control Unit (ACU_1) 493.

[0145] h. Second Access Control Unit (ACU_2) 473.

[0146] i. Hardware Accelerator (ACC) 481 group.

[0147] j. Additional shared caches, such as the L2 cache of the ACC (labeled as "the L2 cache of the ACC") 482.

[0148] k. Interconnect 450.

[0149] l. Third Access Control Unit (ACU_3) 473.

[0150] m. Volatile memory 470, which may store information or commands, such as, cryptographic keys (“cryptographic keys”) 471, codes of one or more hardware accelerators in the hardware accelerator (“ACC codes”) 472, neural network coefficients (“NN coefficients”) 475, and data 474. The volatile memory may be a DRAM memory cell.

[0151] n. Security Unit 464.

[0152] o. Communication Module (“Communication”) 461. Different communication modules may be assigned to different communication protocols or to different initiators.

[0153] The hardware accelerator 481 can be a neural network processor, a programmable array of processing units, and so on. The hardware accelerator can be customized to generate certain types of tasks in a more efficient manner than general-purpose processing units.

[0154] These shared caches may differ from the L2 cache, and their allocation among processing units or hardware accelerators may be similar to... Figure 13 The differences are illustrated in the diagram. For example, a subset of processing units may share a shared cache, a subset of hardware accelerators may share a shared cache, and this shared cache and additional shared caches may be decoupled from each other, multiple interconnects may exist, volatile memory may be different from DRAM memory cells, multiple volatile memory cells may exist, integrated circuits may include one or more non-volatile memory cells, cryptographic units may be located elsewhere, multiple cryptographic units may exist, and so on.

[0155] The first portion 490 of the integrated circuit may include a group of CPU 491, a first ACU 493, and an L2 cache 492 of the CPU. The second portion 480 of the integrated circuit may include a group of a third ACU 483, an ACC 481, and an L2 cache 482 of the ACC. Interconnect 450 may be coupled to the first portion 490, the second portion 480, the cryptographic unit 462, the second ACU 473, and to the communication module 461. Interconnect 450 may be directly or indirectly coupled to an initiator that initiates an access request. The initiator may include any circuit capable of initiating an access request. The initiator may include a sensor, a processing unit, a controller, another integrated circuit, etc.

[0156] Any of the communication modules can be configured to receive access requests (such as read requests and write requests). For simplicity, the following example refers to a write request for a data unit, where the initiator of the write request does not belong to a group of processing units. The write request is used to write the data unit to a target address. The target address can be an address within a memory space supported by volatile memory 470.

[0157] In response to the determination that debugging is permitted, JTAG interface 441 can be configured to receive debug request 441 and participate in debugging. Participation may include participating in the exchange of commands or data between integrated circuit 401 and an external initiator (such as a JTAG tester).

[0158] The debug ACU 484 can be configured to determine whether to allow a debug request. This determination can be conditional upon a debug-permitted decision made by the security element. The security element 464 can be configured to determine whether to enable debug. For example, the security element can be configured to determine whether to enable debug of the processing unit. This determination can be based on other parameters and is not related to a specific debug request. For example, the determination can be based on whether debug can be performed within one or more predefined time periods, where the time period may include the lifetime of the integrated circuit; the expiration of a time period; or after a subsequent reset and boot of the integrated circuit.

[0159] Security element 464 can be configured to determine whether to enable debugging during the security element's boot process. During such a boot process, the security element retrieves boot instructions from non-volatile memory cell 469. In the example, boot code 451 can be executed by security element 464. The boot process may include decrypting encrypted instructions or data stored in memory cells of the integrated circuit. This decryption can be performed using any suitable decryption key and a unique identifier of the processing unit. Security element 464 can be configured to generate debug determination indicators, such as... Figure 16 and Figure 17 The "Enable / Disable JTAG Indicator 447" is mentioned. In the example, the debug determination indicator may be unchangeable except by the debug determination step. The debug determination indicator may be accessible by the security unit or by the access control unit.

[0160] In response to the security unit 464 determining that debugging is enabled, the integrated circuit may wait for a debugging request or respond to a received debugging request via the JTAG interface 441. The debugging ACU 484 may send the debugging request to the verification unit 441' to verify the debugging request. The verification unit 441' or the debugging ACU 484 may perform an authentication process. This authentication may include: sending a challenge question and waiting for a valid challenge response, receiving a password and verifying its validity, etc. The verification may include: using the integrated circuit's public or private key to verify that the party generating the debugging request knows the unique identifier of the processing unit, etc.

[0161] like Figure 17 As shown, integrated circuit 402 is coupled with [other components] by including replacing non-volatile memory cell 468 instead of volatile memory cell 469. Figure 16Unlike integrated circuit 401, the replacement non-volatile memory 469 can be coupled to other parts of the integrated circuit when there is a need to debug the integrated circuit. The secure element 464 can access the replacement non-volatile memory 469 and can participate in the execution of method 600. The secure debugging described herein can be performed against any unit to be debugged. One or more verification steps, such as those appended to or replacing the verification steps performed by verification unit 441', which can be performed by the secure element 464, can restrict access to verification unit 441' by a debugging request. In the example, the secure element 464 can be used to perform one or more verification steps when verification unit 441' restricts access to verification unit 441' by a debugging request.

[0162] In response to determining that a debug request is invalid, the integrated circuit may wait for a subsequent debug request. An invalid debug request may also cause the integrated circuit to generate an alarm or perform any other response. Alternatively, in response to determining that a debug request is valid, security unit 464 may be configured to prepare at least a portion of the integrated circuit for debugging. This preparation may include terminating any programs executed by the processing unit that are not related to debugging before debugging, and may include verifying that termination. This preparation may include erasing any sensitive information from any memory cells accessible by debugging. This preparation may include replacing decrypted data cells or commands with encrypted data cells or commands.

[0163] Available Figure 14 The example shown is of volatile memory prior to preparation. Volatile memory 470 may include stored information or commands, such as a cryptographic key (“cryptographic key”) 471, codes of one or more hardware accelerators in the hardware accelerator (“ACC code 472”), neural network coefficients (“NN coefficients 475”), and data 474. After preparation, non-volatile memory 470 may store debug mode content 479, such as debug-related information or commands. After preparation, volatile memory 470 may also include other encrypted content 479 not related to debugging, such as references... Figure 14 , Figure 15 and Figure 16 As shown and described. This content may include at least a portion of an encrypted version of the cryptographic key 471, the code of ACC code 472, NN coefficients, and data 474. Preparation may include encrypting or removing data or commands unrelated to debugging from any other location on the integrated circuit, such as in shared caches 492 and 482, in any processing unit, in any hardware accelerator, or in any other location. After the debug request has been verified and preparation has been completed, the integrated circuit may participate in debugging.

[0164] Figure 18The diagram illustrates an example of integrated circuit 103. For example... Figure 18 As shown, the debug circuit and its environment 499 can replace the following units of integrated circuit 401: CPU 491, CPU L2 cache 492, ACU_1 493, ACU_2 473, ACC 481, ACC L2 cache 482, interconnect 450 and ACU_2 473.

[0165] This subject matter can also be implemented in a computer program for running on a computer system, including at least a code portion for performing steps of the methods according to this subject matter when running on a programmable device such as a computer system, or enabling the programmable device to perform the functions of a device or system according to this subject matter. The computer program can cause a storage system to allocate disk drives to a group of disk drives.

[0166] A computer program is a list of instructions, such as a specific application or operating system. A computer program may include one or more of the following: subroutines, functions, procedures, object methods, object implementations, executable applications, microapplications, small service programs, source code, object code, shared libraries / dynamically loaded libraries, or other sequences of instructions designed to be executed on a computer system.

[0167] Computer programs may be internally stored on non-transitory computer-readable media. All or some of the computer programs may be provided on computer-readable media that are permanently, removably, or remotely coupled to the information processing system. Computer-readable media may include, for example, but not limited to, any number of the following: magnetic storage media, including disk and magnetic tape storage media; optical storage media (such as compact disk media (e.g., CD-ROM, CD-R, etc.)) and digital video disk storage media; non-volatile memory storage media, including semiconductor-based memory cells (such as flash memory, EEPROM, EPROM, ROM); ferromagnetic digital memory; MRAM; and volatile storage media, including registers, buffers or caches, main memory, RAM, etc.

[0168] A computer process typically includes a program or part of a program that is currently executing (running), its current program values ​​and status information, and the resources used by the operating system to manage the process's execution. The operating system (OS) is software that manages shared computer resources and provides programmers with an interface to access those resources. The operating system processes system data and user input, and responds by allocating and managing tasks and internal system resources as services to users and programs on the system.

[0169] A computer system may include, for example, at least one processing unit, associated memory, and multiple input / output (I / O) devices. When a computer program is executed, the computer system processes information according to the computer program and produces result output information via the I / O devices.

[0170] In the foregoing specification, the subject matter has been described with reference to specific examples of embodiments thereof. However, it will be apparent that various modifications and changes may be made therein without departing from the broader spirit and scope of the subject matter as set forth in the appended claims.

[0171] Furthermore, the terms “front,” “rear,” “top,” “bottom,” “upper,” “lower,” etc. (if any) used in the specification and claims are for descriptive purposes and are not necessarily used to describe permanent relative positions. It should be understood that such terms are interchangeable where appropriate, for example, to enable embodiments of the subject matter described herein to operate in orientations other than those illustrated or otherwise described herein.

[0172] The connections discussed herein can be any type of connection suitable for transmitting signals from, or to, a corresponding node, unit, or device, for example, via an intermediate device. Therefore, unless implied or otherwise indicated, a connection can be, for example, a direct connection or an indirect connection. Connections can be described or illustrated with reference to a single connection, multiple connections, unidirectional connections, or bidirectional connections. However, different embodiments can vary the implementation of the connection. For example, a single unidirectional connection can be used instead of a bidirectional connection, and vice versa. Furthermore, multiple connections can be replaced by a single connection that transmits multiple signals serially or in a time-multiplexed manner. Similarly, a single connection carrying multiple signals can be separated into various different connections carrying subsets of these signals. Therefore, many options exist for transmitting signals.

[0173] Although the polarity of a particular type of conductivity or potential has been described in the examples, it will be understood that the polarity of conductivity type and potential can be reversed.

[0174] Each signal described herein can be designed as either positive or negative logic. In the case of a negative logic signal, the signal is active low when the logic true state corresponds to logic level 0. In the case of a positive logic signal, the signal is active high when the logic true state corresponds to logic level 1. It should be noted that any signal described herein can be designed as either a negative or positive logic signal. Therefore, in alternative embodiments, those signals described as positive logic signals can be implemented as negative logic signals, and those signals described as negative logic signals can be implemented as positive logic signals.

[0175] Furthermore, the terms "assert" or "set" and "invert" (or "deassert" or "clear") are used herein to refer to presenting a signal, status bit, or similar device as its logical true or logical false state, respectively. If the logical true state is logic level 1, then the logical false state is logic level 0. And if the logical true state is logic level 0, then the logical false state is logic level 1.

[0176] Those skilled in the art will recognize that the boundaries between logic blocks are merely illustrative, and that alternative embodiments may combine logic blocks or circuit elements, or impose alternative functional decompositions on various logic blocks or circuit elements. Therefore, it should be understood that the architecture depicted in the text is merely exemplary, and that many other architectures that achieve the same functionality can indeed be implemented.

[0177] Any arrangement of components that perform the same function is effectively “associated” so that the desired function is achieved. Therefore, any two components combined in this paper to achieve a specific function can be considered “associated” with each other in order to achieve the desired function, regardless of the architecture or intermediate components. Similarly, any two such associating components can also be considered “operably connected” or “operably coupled” with each other to achieve the desired function.

[0178] Furthermore, those skilled in the art will recognize that the boundaries between the above operations are merely illustrative. Multiple operations can be combined into a single operation, a single operation can be distributed among additional operations, and operations can be performed with at least partial temporal overlap. Additionally, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be changed in various other embodiments.

[0179] To better illustrate the methods and apparatus disclosed herein, a non-limiting list of exemplary embodiments is provided herein.

[0180] Example 1 is an integrated circuit for secure debugging, the integrated circuit including: a processing unit; an access control unit; and a security unit configured to: determine that debugging is enabled, the debugging enable allowing secure debugging of the processing unit; and verify a debugging request received through a debugging port of the integrated circuit, the verification being in response to the determination of debugging enable; wherein the access control unit is configured to allow debugging of the processing unit in response to the verification; and wherein the integrated circuit is configured to perform debugging of the processing unit in response to the permission for debugging.

[0181] In Example 2, the subject matter as described in Example 1 optionally includes: wherein the verification of the debug request further includes verifying that the debug requesting party that generated the debug request knows the unique identifier of the processing unit.

[0182] In Example 3, the subject matter described in any one or more of Examples 1-2 optionally includes: a security unit further configured to retrieve boot instructions from a non-volatile memory cell of the integrated circuit, wherein: the boot instructions are retrieved during the boot process; and the determination of debug enable is in response to the retrieval of the boot instructions.

[0183] In Example 4, the subject matter as described in Example 3 optionally includes, wherein: the boot process further includes decrypting encrypted data stored in memory cells of the integrated circuit; and the decryption is based on a unique identifier of the processing unit.

[0184] In Example 5, the subject matter as described in Example 4 optionally includes: wherein the encrypted data includes debugging instructions.

[0185] In Example 6, the subject matter described in any one or more of Examples 1-5 optionally includes: the security unit is further configured to generate a debug determination indicator in response to a determination of debug enable, wherein the debug determination indicator is accessible to the access control unit.

[0186] In Example 7, the subject matter as described in Example 6 optionally includes: wherein the debug determination indicator can only be changed by a determination that debug is enabled.

[0187] In Example 8, the subject matter described in any one or more of Examples 1-7 optionally includes: wherein the device is configured to: prepare at least a portion of the integrated circuit for debugging in response to a determination of debugging enable; and further allow debugging of the processing unit in response to the completion of preparation.

[0188] In Example 9, the subject matter described in any one or more of Examples 1-8 optionally includes: wherein preparing for debugging further includes: verifying that any program executed by the processing unit and not related to secure debugging is terminated before secure debugging.

[0189] In Example 10, the subject matter as described in Example 9 optionally includes: wherein preparing for debugging further includes: erasing any sensitive information from any memory cell accessible for secure debugging.

[0190] In Example 11, the subject matter described in any one or more of Examples 1-10 optionally includes: wherein the debug port includes a debug port conforming to the Joint Test Action Group (JTAG).

[0191] In Example 12, the subject matter as described in any one or more of Examples 1-11 optionally includes: wherein the security element includes an access control unit.

[0192] In Example 13, the subject matter described in any one or more of Examples 1-12 optionally includes: wherein the security element is separate from the access control unit.

[0193] Example 14 is a method for securely debugging a processing unit of an integrated circuit, the method comprising: determining debugging enabled by a security element of the integrated circuit, the debugging enabling allowing secure debugging of the processing unit; verifying a debugging request received through a debugging port of the integrated circuit, the verification of the debugging request being in response to the determination of debugging enabled; allowing debugging of the processing unit by an access control unit of the integrated circuit in response to the verification of the debugging request; and performing debugging of the processing unit in response to the permission of debugging.

[0194] In Example 15, the subject matter as described in Example 14 optionally includes: wherein verification of the debug request further includes verifying that the debug requesting party that generated the debug request knows the unique identifier of the processing unit.

[0195] In Example 16, the subject matter as described in any one or more of Examples 14-15 optionally includes: wherein the debug port includes a debug port conforming to the Joint Test Action Group (JTAG).

[0196] In Example 17, the subject matter described in any one or more of Examples 14-16 optionally includes: retrieving boot instructions from a non-volatile memory cell of an integrated circuit by a security element, wherein: the boot instructions are retrieved during the boot process; and the determination of debug enable is in response to the retrieval of the boot instructions.

[0197] In Example 18, the subject matter as described in Example 17 optionally includes, wherein: the boot process further includes decrypting encrypted data stored in a memory cell of an integrated circuit; and the decryption is based on a unique identifier of the processing unit.

[0198] In Example 19, the subject matter as described in Example 18 optionally includes: wherein the encrypted data includes debugging instructions.

[0199] In Example 20, the subject matter described in any one or more of Examples 14-19 optionally includes: generating a debug determination indicator in response to a determination of debug enable, wherein the debug determination indicator is accessible to the access control unit.

[0200] In Example 21, the subject matter as described in Example 20 optionally includes: wherein the debug determination indicator can only be changed by a determination that debug is enabled.

[0201] In Example 22, the subject matter described in any one or more of Examples 14-21 optionally includes: preparing at least a portion of an integrated circuit for debugging in response to a determination of debugging enable; wherein further debugging of the processing unit is permitted in response to the completion of preparation.

[0202] In Example 23, the subject matter as described in Example 22 optionally includes: wherein preparing for debugging further includes: verifying that any programs executed by the processing unit and not related to secure debugging are terminated before secure debugging.

[0203] In Example 24, the subject matter described in any one or more of Examples 22-23 optionally includes: wherein preparing for debugging further includes: erasing any sensitive information from any memory cell accessible for secure debugging.

[0204] In Example 25, the subject matter described in any one or more of Examples 14-24 optionally includes: wherein the security element includes an access control unit.

[0205] In Example 26, the subject matter described in any one or more of Examples 14-25 optionally includes: wherein the security element is separate from the access control unit.

[0206] Example 27 is at least one non-transient machine-readable storage medium comprising a plurality of instructions executed in response to a processor circuitry of a computer-controlled device, causing the computer-controlled device to: determine debug enable by a security element of an integrated circuit, the debug enable allowing secure debugging of a processing unit; verify a debug request received through a debug port of the integrated circuit, the verification in response to the determination of debug enable; allow debugging of the processing unit by an access control unit of the integrated circuit in response to the verification of the debug request; and perform debugging of the processing unit in response to the permission of debugging.

[0207] In Example 28, the subject matter as described in Example 27 optionally includes: wherein verification of the debug request further includes verifying that the debug requesting party that generated the debug request knows the unique identifier of the processing unit.

[0208] In Example 29, the subject matter described in any one or more of Examples 27-28 optionally includes: instructions further causing a computer-controlled device to retrieve boot instructions from a non-volatile memory cell of an integrated circuit, wherein: the boot instructions are retrieved during the boot process; and the determination of debug enable is in response to the retrieval of the boot instructions.

[0209] In Example 30, the subject matter as described in Example 29 optionally includes, wherein: the boot process further includes decrypting encrypted data stored in memory cells of an integrated circuit; and the decryption is based on a unique identifier of the processing unit.

[0210] In Example 31, the subject matter as described in Example 30 optionally includes: wherein the encrypted data includes debugging instructions.

[0211] In Example 32, the subject matter described in any one or more of Examples 27-31 optionally includes: instructions further causing a computer-controlled device to generate a debug determination indicator in response to a determination of debug enable, wherein the debug determination indicator is accessible to the access control unit.

[0212] In Example 33, the subject matter as described in Example 32 optionally includes: wherein the debug determination indicator can only be changed by a determination that debug is enabled.

[0213] In Example 34, the subject matter described in any one or more of Examples 27-33 optionally includes: instructions further causing a computer-controlled device to prepare at least a portion of an integrated circuit for debugging in response to a determination of debugging enable; wherein debugging of the processing unit is further permitted in response to the completion of preparation.

[0214] In Example 35, the subject matter described in any one or more of Examples 27-34 optionally includes: wherein preparing for debugging further includes: verifying that any program executed by the processing unit and not related to secure debugging is terminated prior to secure debugging.

[0215] In Example 36, the subject matter as described in Example 35 optionally includes: wherein preparing for debugging further includes: erasing any sensitive information from any memory cell accessible for secure debugging.

[0216] In Example 37, the subject matter as described in any one or more of Examples 27-36 optionally includes: wherein the debug port includes a debug port conforming to the Joint Test Action Group (JTAG).

[0217] In Example 38, the subject matter described in any one or more of Examples 27-37 optionally includes: wherein the security element includes an access control unit.

[0218] In Example 39, the subject matter described in any one or more of Examples 27-38 optionally includes: wherein the security element is separate from the access control unit.

[0219] The illustrated examples can be implemented as circuits located on a single integrated circuit or within the same device. Alternatively, these examples can be implemented as any number of separate integrated circuits or separate devices interconnected in a suitable manner. The examples or portions thereof can be implemented as physical circuits or soft or code representations that can be converted into a logical representation of physical circuits, such as in any suitable type of hardware description language.

[0220] This subject matter is not limited to physical devices or units implemented in non-programmable hardware, but can also be applied to programmable devices or units that can perform desired device functions by operating according to appropriate program code, such as mainframes, minicomputers, servers, workstations, personal computers, notebook computers, personal digital assistants, video games, automotive and other embedded systems, cellular phones and various other wireless devices, generally referred to as "computer systems" in this application.

[0221] Other modifications, variations, and alternatives are also possible. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

[0222] In the claims, any reference numerals enclosed in parentheses should not be construed as limiting the claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in the claims. Furthermore, the terms “a” or “an” as used herein are defined as one or more. Additionally, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed as implying that the introduction of another claim element by the indefinite article “a” or “an” limits any particular claim containing such introduced claim element to a subject containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”. The same applies to the use of definite articles. Unless otherwise stated, terms such as “first” and “second” are used to arbitrarily distinguish the elements described by such terms. Therefore, these terms are not necessarily intended to indicate the time or other priority of such elements. The mere fact that certain measures are recited in mutually different claims does not imply that combinations of these measures cannot be advantageously used.

[0223] While certain features of the subject matter have been illustrated and described herein, many modifications, substitutions, alterations, and equivalents will now occur to those skilled in the art. Therefore, it should be understood that the appended claims are intended to cover all such modifications and alterations that fall within the true spirit of the subject matter.

Claims

1. An integrated circuit for secure debugging, the integrated circuit comprising: Processing unit; Access control unit; as well as Security element, the security element being configured to: During the boot process, boot instructions are retrieved from the non-volatile memory cells of the integrated circuit; In response to the retrieval of the boot command, debugging is enabled, which allows secure debugging of the processing unit; Verify a debug request received through the debug port of the integrated circuit, the verification being in response to the determination that the debug is enabled, and the verification including verifying that the debug requester knows the unique identifier of the processing unit; as well as At least a portion of the integrated circuit is made ready for debugging by erasing sensitive information from memory cells accessible by the secure debugger. The security unit is further configured to generate a debug determination indicator in response to the determination that debug is enabled, wherein the debug determination indicator is accessible to the access control unit, and wherein the debug determination indicator can only be changed by the determination that debug is enabled. The access control unit is configured to allow debugging of the processing unit in response to the verification; and The integrated circuit is configured to perform debugging of the processing unit in response to permission to perform debugging.

2. The integrated circuit as claimed in claim 1, wherein, The verification of the debug request further includes verifying that the debug requester who generated the debug request knows the unique identifier of the processing unit.

3. The integrated circuit as claimed in claim 1, wherein: The boot process further includes decrypting encrypted data stored in the memory cells of the integrated circuit; and The decryption is based on the unique identifier of the processing unit.

4. The integrated circuit as described in claim 3, wherein, The encrypted data includes debugging instructions.

5. The integrated circuit as claimed in claim 1, wherein, The security unit is configured to: In response to the determination that debugging is enabled, at least a portion of the integrated circuit is prepared for debugging; and Further, in response to the completion of the preparation, the debugging of the processing unit is permitted.

6. The integrated circuit as claimed in claim 1, wherein, Making the process ready for debugging further includes verifying that any programs executed by the processing unit that are not related to the security debugging have been terminated before the security debugging is performed.

7. The integrated circuit of claim 1, wherein the security unit includes the access control unit.

8. The integrated circuit of claim 1, wherein the security unit and the access control unit are separate.

9. A method for securely debugging a processing unit of an integrated circuit, the method comprising: The security unit of the integrated circuit retrieves boot instructions from a non-volatile memory cell during the boot process; The security unit determines whether debugging is enabled in response to the detection of the boot command, and the debugging enablement allows secure debugging of the processing unit. Enabling debugging includes: A debug determination indicator is generated in response to the determination that debug is enabled, wherein the debug determination indicator is accessible to the access control unit, and wherein the debug determination indicator can only be changed by the determination that debug is enabled; Verify a debug request received through the debug port of the integrated circuit, the verification including verifying that the debug requester knows the unique identifier of the processing unit, the verification being in response to the determination that the debug is enabled; At least a portion of the integrated circuit is made ready for debugging by erasing sensitive information from memory cells accessible by the secure debugger. The access control unit of the integrated circuit, in response to the verification of the debug request, allows debugging of the processing unit; and The debugging of the processing unit is performed in response to the permission granted for the debugging.

10. The method of claim 9, wherein, The verification of the debug request further includes verifying that the debug requester who generated the debug request knows the unique identifier of the processing unit.

11. The method of claim 10, wherein, The debug ports include debug ports compliant with the Joint Test Action Group (JTAG).

12. The method of claim 9, wherein: The boot process further includes decrypting encrypted data stored in the memory cells of the integrated circuit; and The decryption is based on the unique identifier of the processing unit.

13. The method of claim 12, wherein, The encrypted data includes debugging instructions.

14. The method of claim 9, further comprising: In response to the determination that the debugging is enabled, at least a portion of the integrated circuit is made ready for debugging; as well as The debugging of the processing unit is further responsive to the completion of the preparation.

15. The method of claim 14, wherein, Making the process ready for debugging further includes verifying that any programs executed by the processing unit that are not related to the security debugging have been terminated before the security debugging is performed.

16. At least one non-transient machine-readable storage medium comprising a plurality of instructions that, in response to execution by a processor circuitry of a computer-controlled device, cause the computer-controlled device to perform the method according to any one of claims 9-15.

17. An apparatus for securely debugging a processing unit of an integrated circuit, the apparatus comprising: A means for retrieving boot instructions from a non-volatile memory cell of the integrated circuit during the boot process; A means for determining debug enable by a security element of the integrated circuit in response to the retrieval of a boot instruction, the debug enable allowing secure debugging of the processing unit, the means for determining debug enable comprising: means for generating a debug enable indicator in response to the determination of debug enable, wherein the debug enable indicator is accessible to an access control unit, wherein the debug enable indicator can only be changed by the determination of debug enable; A means for verifying a debug request received through the debug port of the integrated circuit, wherein the verification of the debug request is in response to the determination of debug enable, the means for verifying the debug request includes means for verifying that the requesting party knows the unique identifier of the processing unit. A means for preparing at least a portion of an integrated circuit for debugging by erasing sensitive information from a memory cell accessible by the secure debugging; Means for allowing debugging of the processing unit by the access control unit of the integrated circuit in response to the verification of the debugging request; and The debugging of the processing unit is performed in response to the permission granted for the debugging.

Images