Compatibility of peripheral equipment with safety circuit systems

Abstract

The IC chip can provide silicon root of trust (RoT) functionality. In the described implementation, the IC chip includes a processor (202), an interconnect (110) and a plurality of peripherals (250). These compatible circuit components are designed to facilitate interoperability and consistent expected communications of a secure circuit system. Each peripheral includes an interface (302) that complies with a common framework for interacting with the processor and other peripherals. The interface includes an interconnect interface (304) that couples the peripheral to an interconnect and an inter-device interface (306) that couples the peripheral to at least one other peripheral. According to the inter-device scheme of the interface specification, the peripheral is implemented based on a peripheral design code that indicates inter-device signaling (316). The manufacturer manufactures the peripheral based on the design code so as to be physically and logically coupled to another peripheral in a predictable manner. This facilitates a more robust and reliable secure circuit system.

Description

Background Art

[0001] Electronic devices play an integral role in manufacturing, communications, transportation, healthcare, commerce, social interaction, and entertainment. For example, electronic devices power server farms, which provide cloud-based distributed computing capabilities for commerce and communications. Electronic devices are also embedded in many different types of modern devices, from medical devices to appliances, and from vehicles to industrial tools. Personal electronic devices enable portable video viewing and convenient access to smart digital assistants. In addition, one multifunctional electronic device—the smartphone—has become a virtual necessity at your fingertips. As electronic devices have become ubiquitous and essential to many aspects of modern life, device security has become imperative.

[0002] Many people are familiar with malware, which is sometimes collectively referred to as "computer viruses." Some malware is designed to gain unauthorized access to information stored on electronic devices or to otherwise harm electronic devices. Several strategies can help protect users' devices and information from security threats by combating certain types of malware. These strategies include adopting and regularly updating resilient operating systems, engaging in secure computing practices, and installing anti-malware programs. Unfortunately, these strategies cannot protect electronic devices from all malware attacks.

[0003] Furthermore, electronic devices may also be vulnerable to other types of attacks in addition to those performed by software-based malware. For example, the safe and secure operation of electronic devices and the security of information stored by such devices may be compromised by physical attacks on the hardware and radio frequency attacks on wireless communications. In other words, certain forms of attack can circumvent or undermine the strategies listed above, enabling bad actors to compromise electronic devices and gain access to any accounts used with the device.

[0004] An electronic device includes at least one integrated circuit (IC) that provides intelligence to enable various functions. These functions promote business, simplify healthcare access, provide entertainment, support social media interaction, and enable the above-mentioned other services. Electronic devices can also store or otherwise utilize information to be protected. In order to support these functions and promote safe operation, some electronic devices include hardware-based protection in the form of a secure circuit system as part of the IC. Unfortunately, existing secure circuit system methods are not enough to counter the various software, hardware, and wireless attacks launched against electronic devices today. Summary of the invention

[0005] Certain electronic devices, such as server computers and smart phones, are responsible for providing services to users. Users rely on these electronic devices to obtain key services accessed using one or more accounts, such as those for financial services or air travel. Due to the link between the electronic device and the account, a damaged electronic device may allow undesired access to services linked to the account or allow unauthorized access to the account itself. In addition, in order to provide services associated with the account, these electronic devices may store account-related information that needs to be protected, such as financial data, user names, passwords, and keys for encryption. Unfortunately, anti-malware programs cannot prevent all attack paths for electronic devices. For example, anti-malware programs may not be able to provide protection for direct physical attacks using microprobes to detect voltage levels on integrated circuit (IC) chips. Therefore, it is beneficial to incorporate hardware-based measures that can identify, block, repel or otherwise thwart attacks on electronic devices, including resisting physical attacks, into electronic devices.

[0006] Thus, electronic devices may include security circuit systems to combat attacks from bad actors. In some cases, the security circuit system detects inappropriate or suspicious activity and takes protective measures. The security circuit system can be implemented in different ways. For example, computer engineers can manufacture the security circuit system as a standalone IC chip or as part of another chip, such as a system on a chip (SoC). In either case, the security circuit system can be part of a protected enclave, a trusted chip platform, a hardware-based root of trust (RoT) (e.g., a silicon RoT), or a combination thereof. Regardless of how or where the security circuit is incorporated into the electronic device, computer engineers can design the security circuit to combat many different types of attacks, as described below.

[0007] Attacks on electronic devices can take the form of programs that observe screen images or monitor repetitive behavior to infer information, applications that attempt to read data from protected areas of memory, and direct physical probing of circuit systems. The secure circuit system performs multiple functions to combat one or more of these attacks. For example, the secure circuit system can protect encryption keys during use, transmission, or storage. To this end, dedicated memory and dedicated data buses can be used. The secure circuit system can also generate high-quality pseudo-random numbers or run an encryption engine in an area separate from applications that may run as malware. In addition, the secure circuit system can ensure that the hardware is started using the correct, untampered startup basic input / output system (BIOS).

[0008] Thus, a security circuit system may be responsible for implementing multiple functions to combat various attacks on electronic devices. However, existing approaches to security circuit systems employ specially designed hardware architectures. Different circuit portions of the security circuit system may also be designed to be relatively isolated from each other. As a result, circuit portions designed to combat various security threats may not interoperate as expected, making the hardware less secure. Furthermore, poor inter-component communication creates another avenue of attack for potential bad actors. Furthermore, this specialized approach makes the design and testing phases of the security circuit system more arduous, time consuming, and costly. This may result in certain security threats being overlooked or not adequately addressed when developing the security architecture. As a result, these specialized architectures make it more difficult to protect electronic devices from a variety of different security threats.

[0009] In contrast, this document describes means for providing an adaptable and flexible framework or platform that can produce resilient and programmable secure hardware to counter various forms of attack on electronic devices. In some implementations of secure circuit systems, different types of circuits or portions of circuits that provide different security-related functions communicate using an extended protocol that still produces specific and consistent signaling. The communication protocol enables circuits that provide different security-related functions to interact seamlessly according to a specified design framework.

[0010] Design frameworks and communication protocols produce compatible components so that even circuit components that are designed separately from each other are suitable for being deployed together consistently with stable, predictable interactions. For example, communications and other forms of interaction (e.g., sharing of resources such as buses, interfaces, or memory) can be at least partially standardized to provide a measure of predictability and interoperability. As used herein, "compatible components" include those components that are designed to adhere to a common framework so that the components are suitable for use together. In some cases, compatibility provides a degree of plug-and-play capability between two or more security-related components of an integrated circuit chip.

[0011] In some implementations, in addition to the processor and interconnect, the secure circuit system includes a plurality of peripherals. Each of the plurality of peripherals performs some function that contributes to the security or proper operation of the secure circuit system. Thus, each peripheral can provide core or support security-related functions. The functions, such as controlling access to data or performing cryptographic operations, support the overall purpose of the secure circuit system, including providing features to enable secure computing through other circuit systems and / or ICs of the electronic device. For predictability and interoperability, each peripheral can be implemented as a compatible component.

[0012] To produce compatible parts, each peripheral device can be designed to adhere to a specified communication interface. Since each peripheral device communicates according to the same or coordinated communication protocol, the possibility of interoperability is much greater. Therefore, computer engineers and computer scientists can focus on designing the safety-related functions of each peripheral device. This enables the production of superior safety circuit systems for at least two reasons. First, the planned communication between two or more peripheral devices occurs as expected because each peripheral device follows the same design interface specifications. Second, the man-hours invested in the safety circuit system can be allocated to designing and testing safety functions rather than detecting and debugging inter-component communication problems.

[0013] In an example implementation, each peripheral device includes an interface designed to comply with an interface specification to use a common or coordinated communication protocol. The communication interface may include an interconnect interface that interacts with a main interconnect or host processor, an inter-device interface that interacts with other peripheral devices, or another interface for other signals entering or leaving a given peripheral device. Another interface may specify how the peripheral device communicates with at least one chip input / output interface and with at least one interrupt signal, etc. using one or more clock signals. For example, to generate an inter-device interface, design code for the peripheral device is prepared based on the inter-device scheme of the interface specification. Thus, the design code identifies the attributes to be used by the peripheral device, such as inter-device signals.

[0014] The interface specification may also define a register interface for a peripheral device. Here, each register of the register interface may be used for control, status, or communication. For example, an interrupt register may be instantiated for communication between, for example, a peripheral device and a processor. An interrupt register may include an interrupt enable indication, an interrupt status indication, and an interrupt test indication. These indications may be used to provide consistent interaction between a host processor and a peripheral device to handle interrupts. In other implementations, the peripheral device participates in compatible communications for alarm handling and alarm escalation.

[0015] In these approaches, the safety circuit system can be incorporated into the silicon RoT chip and / or SoC. The safety circuit system includes multiple peripherals, each of which is compatible with other peripherals to ensure expected compatibility and consistent communication between peripherals. By adhering to the communication framework, the design efforts of the peripherals can be focused on the safety-related functions. Therefore, by utilizing the defined inter-device communication set forth in the communication interface specification, adaptable and diverse safety responses can be achieved in a predictable manner.

[0016] The aspects described below include an integrated circuit for compatibility of peripheral devices with a secure circuit system. The secure circuit system of the integrated circuit includes an interconnect, a processor coupled to the interconnect, and a plurality of peripheral devices. Each corresponding peripheral device is coupled to the interconnect and includes an interface configured to comply with a common framework for interacting with the processor and other peripheral devices in the plurality of peripheral devices. The interface includes an interconnect interface configured to couple the corresponding peripheral device to the interconnect. The interface also includes an inter-device interface, which is configured to couple the corresponding peripheral device to other peripheral devices in the plurality of peripheral devices.

[0017] The aspects described below include a method for compatibility of a peripheral device with a secure circuit system, which can be performed by at least a portion of an integrated circuit. The method includes a processor communicating with a peripheral device in a plurality of peripheral devices based on an interconnection scheme according to a common framework for interaction between the processor and the plurality of peripheral devices through an interconnection. The method also includes a peripheral device communicating with the processor through an interconnection based on an interconnection scheme according to a common framework. The method also includes a peripheral device communicating with another peripheral device in a plurality of peripheral devices based on an inter-device scheme according to a common framework for interaction between at least two peripheral devices in a plurality of peripheral devices.

[0018] Aspects described below include a method for compatibility of a peripheral device with a secure circuit system, which method can be performed by at least a portion of an integrated circuit. The method includes receiving a peripheral device design code corresponding to a peripheral device of the secure circuit system, wherein the peripheral device design code includes one or more indications of inter-device signaling. The method also includes analyzing the peripheral device design code, including comparing the one or more indications of inter-device signaling with an inter-device scheme of an interface specification of a common framework for communicating at least within the secure circuit system. The method also includes, in response to the analysis, providing a compatibility report indicating whether the peripheral device design code is consistent with the inter-device scheme of the interface specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Apparatus and techniques for compatibility of peripheral devices with safety circuit systems are described with reference to the following drawings. The same numerals are used throughout the drawings to represent the same features and components.

[0020] Figure 1 An example apparatus having an integrated circuit (IC) including secure circuitry that may enable peripheral device compatibility is illustrated.

[0021] Figure 2 An example security circuit system comprising a plurality of circuit components is illustrated, including a plurality of example peripheral devices that may be implemented to be compatible.

[0022] Figure 3An example peripheral device including at least one interface to support compatibility with other circuit components is illustrated.

[0023] Figure 4 An example approach to analyzing a peripheral device design to ensure compatibility goals are met is illustrated.

[0024] Figure 5-1 An example peripheral device including a register interface and example communication signals is illustrated.

[0025] Figure 5-2 An example register interface with multiple interrupt entries is illustrated.

[0026] Figure 5-3 An example interrupt entry is illustrated.

[0027] Figure 5-4 An example timing diagram for handling interrupts between a peripheral device and a processor is illustrated.

[0028] Figure 6 An example communication relationship between an alarm receiver module of an alarm handler and an alarm transmitter module of a peripheral device is illustrated.

[0029] Figure 7 An example communication relationship between an upgrade transmitter module of an alarm handler and an upgrade receiver module of an upgrade handler-type peripheral device is illustrated.

[0030] Figure 8 An example method for an apparatus to achieve compatibility of a peripheral device with a secure circuit system is illustrated.

[0031] Fig. 9 Other example methods of the illustrated apparatus for achieving compatibility of peripheral devices with secure circuit systems.

[0032] Fig.10 Various components of an example electronic device are shown that can implement compatibility of a peripheral device with a secure circuit system according to one or more aspects described. DETAILED DESCRIPTION

[0033] Overview

[0034] Electronic devices make important contributions to modern society, such as those used for communications, security, and manufacturing. Every electronic device relies on integrated circuits (ICs) with processing power to provide some functionality. Due to the critical nature of many of these functions, electronic devices may include ICs with secure circuitry to provide protection. Secure circuitry reduces the chances of information being inadvertently exposed or some functions being used in a harmful or unauthorized manner. Secure circuitry can be implemented in a variety of forms, one of which involves the root of trust (RoT) paradigm.

[0035] With silicon RoT, hardware-based mechanisms keep computing secure in terms of preventing improper access to information and blocking unauthorized use of devices. Silicon RoT principles can help ensure that both the hardware infrastructure and the software executing on it remain in their intended, trustworthy state. To this end, silicon RoT can verify that critical system components boot securely using authorized and verifiable code. As a result, it can ensure that a server or another electronic device boots with the correct firmware and that the firmware has not been infected with low-level malware. Silicon RoT can provide additional or alternative security advantages. For example, it can provide a cryptographically unique machine identity; this unique identity enables operators to verify that the electronic device is legitimate. In addition, it can maintain encryption keys and other information in tamper-proof silos, which can prevent even those with physical access to the device from obtaining information. RoT services anchored in hardware can also provide authoritative, tamper-proof audit records and other runtime security services.

[0036] Chip designers can incorporate silicon RoT technology into a single IC chip focused on providing security functionality. Alternatively, RoT silicon can be integrated with other circuit systems, including in a central processing unit (CPU) chip or package, in a graphics processing unit (GPU) chip or card, in a system on chip (SoC), and in a memory storage device. Typically, secure circuit systems can operate in server motherboards, network cards, client devices (such as laptops and smartphones), consumer routers, Internet of Things (IoT) devices, and fixed and portable storage units, to name just a few examples. By anchoring the RoT in silicon, computing security is enhanced at the hardware, firmware, and software levels, regardless of the application or electronic device. Silicon RoT also enhances security on different devices that communicate with each other directly or over a network. Although some security and circuit design principles are described in this document using a silicon or hardware RoT environment, this is done only as an example because the principles described apply generally to secure circuit systems.

[0037] In today's computing environment, bad actors can attack electronic devices at countless levels using a variety of attack vectors. For example, an attack could use malware transmitted over the Internet to attempt to obtain information stored on a laptop that the user would like to keep safe. Additionally, an attack could involve injecting malware into an electronic device during transportation or when the device is operating in an unobserved location—such as a As another example, a bad actor may steal an electronic device and have enough time to conduct a direct physical attack on the device. This direct physical attack can include cutting wires, probing voltages, and repeatedly running code to observe trends and infer information.

[0038] Thus, a secure circuit system may be responsible for implementing multiple functions to combat various attacks on electronic devices. However, existing secure circuit system approaches employ ad hoc designed hardware architectures. Different circuit portions of the secure circuit system may also be designed to be relatively isolated from each other. Therefore, circuit portions designed to combat various security threats may not interoperate as expected, making the hardware less secure. Furthermore, poor inter-component communication creates another avenue of attack for potential bad actors. Furthermore, this ad hoc approach makes the design and testing phases of the secure circuit system more arduous, time-consuming, and costly. This may result in certain security threats being overlooked or not adequately addressed when developing the security architecture. Therefore, these ad hoc architectures make it more difficult to protect electronic devices from a variety of different security threats.

[0039] In contrast, the document describes methods for providing an adaptable and flexible framework or platform that can produce resilient and programmable secure hardware to counter various forms of attacks on electronic devices. In some implementations of secure circuit systems, different types of circuits or portions of circuits that provide different security-related functions communicate using an extended protocol that still produces specific and consistent signaling. The communication protocol enables circuits that provide different security-related functions to interact seamlessly according to a specified design framework.

[0040] The design framework and communication protocols produce compatible components so that even circuit components that are designed separately from each other are suitable for being deployed together consistently with stable, predictable interactions. For example, communications and other forms of interaction (e.g., sharing of resources such as buses, interfaces, or memory) can be at least partially standardized to provide a measure of predictability and interoperability. As used herein, "compatible components" include those components that are designed to adhere to a common framework so that the components are suitable for use together. In some cases, compatibility provides a degree of plug-and-play capability between two or more security-related components of an integrated circuit chip.

[0041] In some implementations, in addition to the processor and interconnects, the secure circuit system includes a plurality of peripherals. Each of the plurality of peripherals performs some function that contributes to the security or proper operation of the secure circuit system. Thus, each peripheral may provide core or support security-related functionality. This functionality, such as controlling access to data or performing cryptographic operations, supports the overall purpose of the secure circuit system, which includes providing features to enable secure computing through other circuit systems and / or ICs of the electronic device. For predictability and interoperability, each peripheral may be implemented as a compatible component.

[0042] To produce compatible parts, each peripheral device can be designed to adhere to a specified communication interface. Since each peripheral device communicates according to the same or coordinated communication protocol, the possibility of interoperability is much greater. Therefore, computer engineers and computer scientists can focus on designing the safety-related functions of each peripheral device. This enables the production of superior safety circuit systems for at least two reasons. First, planned communication between two or more peripheral devices occurs as expected because each peripheral device adheres to the same design interface specifications. Second, the man-hours invested in the safety circuit system can be allocated to designing and testing safety functions rather than detecting and debugging inter-component communication problems.

[0043] In an example implementation, each peripheral device includes an interface designed to comply with an interface specification to use a common or coordinated communication protocol. The communication interface may include an interconnect interface for interacting with a main interconnect or host processor, an inter-device interface for interacting with other peripheral devices, or another interface for other signals entering or leaving a given peripheral device. Another interface may specify how the peripheral device communicates with at least one chip input / output interface and with at least one interrupt signal, etc. using one or more clock signals. For example, to generate an inter-device interface, design code for the peripheral device is prepared based on an inter-device scheme of the interface specification. Thus, the design code identifies the properties to be used by the peripheral device, such as inter-device signals. In the following reference Figure 3 , 4 and 5-1 describe examples of peripheral device interfaces and design code analysis.

[0044] The interface specification may also define a register interface for the peripheral device. Here, each register of the register interface may be used for control, status, or communication. For example, an interrupt register may be instantiated for communication between, for example, a peripheral device and a processor. The interrupt register may include an interrupt enable indication, an interrupt status indication, and an interrupt test indication. These indications may be used to provide consistent interaction between the host processor and the peripheral device. Figures 5-2 to 5-4 Examples of using interrupts in a safety circuit system in a compatible manner are described. This document also describes other aspects and implementations of compatibility of peripheral devices with safety circuit systems. Each of these aspects and implementations described herein can be used alone or in any combination.

[0045] In other implementations, device peripherals may exchange alerts. Typically, alerts are considered more important or more concerning than interrupts. In other words, security risks that should not be ignored in a RoT or other secure silicon environment may be designated as alerts rather than basic or default processor interrupts. Nonetheless, the system may still attempt to leverage the intelligence and resources of the processor to resolve the potential security event. If the processor fails to resolve the interrupt, a peripheral device called an alarm handler takes remedial action, including potentially directing the activation of security countermeasures. In accordance with the described implementation, other peripheral devices may transmit alarm indications to the alarm handler in a prescribed manner. The signaling path between modules in the alarm handler and modules in the peripheral device may be implemented via differential paths to promote resiliency. In addition, the alarm handler or alarm sending peripheral device may include an integrity failure circuit system that checks for proper differential functionality of the signaling path. In other implementations, the alarm handler escalates unresolved alarms, and the escalated handler may activate countermeasures in response. In reference below Figure 6 and 7 Examples of alarm handling and escalation are described, including associated communication signaling that may be made compatible.

[0046] In these ways, a secure circuit system can be incorporated into a silicon RoT chip and / or SoC. The secure circuit system includes multiple peripherals, each of which is compatible with other peripherals to ensure expected compatibility and consistent communication between peripherals. By adhering to the communication framework, the design effort of the peripherals can be focused on security-related functions. Therefore, by leveraging defined device-to-device communications set forth in the communication interface specification, adaptable and diverse security responses can be achieved in a predictable manner. Although some aspects of compatibility are described in the context of a secure circuit system, the disclosed compatibility concepts are applicable to the design, creation, and operation of circuit systems of other types and purposes.

[0047] The following discussion discusses example implementations at various levels of detail with reference to the relevant figures. The following discussion first sets forth an example operating environment, then describes example hardware, schemes, and techniques. Thereafter, example methods are described with reference to flowcharts or diagrams. Finally, an example computing device is described.

[0048] Example operating environment for compatibility of peripheral devices with safety circuit systems

[0049] Figure 1An example device 102 having an integrated circuit 104 (IC 104) including a secure circuit system 106 is generally shown at 100. Device 102, integrated circuit 104, and / or secure circuit system 106 may implement the compatibility of peripheral devices and secure circuit systems described herein. In this example, device 102 is depicted as a smartphone. However, device 102 may be implemented as any suitable computing or electronic device.

[0050] Examples of apparatus 102 include a mobile electronic device, a mobile communication device, a modem, a cellular or mobile phone, a mobile station, a gaming device, a navigation device, a media or entertainment device (e.g., a media streamer or game controller), a laptop computer, a desktop computer, a tablet computer, a smart appliance, an in-vehicle electronic system, a wearable computing device (e.g., clothing, a watch, or reality-altering glasses), an Internet of Things (IoT) device, a sensor, an inventory management device, an electronic portion of a machine or device (e.g., a vehicle or robot), a memory storage device (e.g., a solid-state drive (SSD)), and a server computer or a portion thereof (e.g., a server blade or a rack or another portion of a data center), etc. Illustrated examples of apparatus 102 include a tablet device 102-1, a smart TV 102-2, a desktop computer 102-3, a server computer 102-4, a smart watch 102-5, a smartphone (or document reader) 102-6, and smart glasses 102-7.

[0051] In an example implementation, the device 102 includes at least one integrated circuit 104. The integrated circuit 104 can be mounted on a module, a card, or a printed circuit board (PCB) (not shown). Examples of PCBs include flexible PCBs, rigid PCBs, single-layer or multi-layer PCBs, surface mount or through-hole PCBs, and combinations thereof, and the like. Each integrated circuit 104 can be implemented as a general-purpose processor, a system on a chip (SoC), a security-oriented IC (e.g., a RoT IC chip), a memory chip, a communication IC (e.g., a modem or a radio frequency IC), a graphics processor, an artificial intelligence (AI) accelerator, and combinations thereof, and the like. The integrated circuit 104 can be packaged alone or together with other IC chips.

[0052] As shown, integrated circuit 104 includes a secure circuit system 106. Secure circuit system 106 may include multiple parts, including: multiple circuit components 108-1...108-C, where C represents a positive integer; and interconnect 110. In addition to interconnect 110, examples of circuit components 108 include a processor and multiple peripheral devices. These are shown in FIG. Figure 2 is depicted in and described below. Figure 1108 -C and interconnect 110 may be integrated together on a single IC as shown, the components may also be distributed across two or more ICs. The secure circuit system 106 may be implemented, for example, as a protected enclave, a trusted chip platform, and a hardware-based root of trust (RoT) chip (e.g., silicon RoT), among others. Regardless of how or where the secure circuit 106 is incorporated into the electronic device, the secure circuit 106 may be able to combat many different types of attacks.

[0053] In example operation, once an attack - or potential attack - is detected or an anomaly occurs, some components generate an alarm 112 or an interrupt 114. For example, a circuit component 108 can generate an alarm 112 and can transmit the alarm 112 to an alarm handler, as described below. Additionally or alternatively, another circuit component 108 can generate an interrupt 114 for processing by the processor. Alarms 112, interrupts 114 and other signals are transmitted between two or more components 108 according to a common framework for interaction between a processor and / or peripheral devices of a secure circuit system 106. The common framework can specify interfaces and signaling at each peripheral device to facilitate interoperability and the use of consistent communication protocols across multiple peripheral devices. Therefore, while certain aspects of compatibility are presented in terms of secure circuit systems, peripheral device compatibility can also be used for other types of circuit systems. This document describes an example framework as well as an example communication interface. Reference Figure 3 and 4 Describes an example communication interface and interface specifications. Figures 5-1 to 5-4 Describes an example signaling scheme and the corresponding hardware, with an emphasis on interrupts. However, reference Figure 2 , an example architecture of the safety circuit system 106 is described next.

[0054] Figure 2 An example security circuit system 106 is illustrated, which includes multiple circuit components, including multiple example peripheral devices 250 that can be implemented to be compatible. As shown, the security circuit system 106 includes a processor 202 coupled to an interconnect 110. The interconnect 110 can be implemented using, for example, a bus, a switch fabric, or a bus network that enables various circuit components to communicate. In addition to the interconnect 110 and the processor 202, a plurality of circuit components 108-1...108-C ( Figure 1 ) may include multiple memories and multiple peripheral devices. Each of the processor 202, multiple memories, and multiple other peripheral devices 250 is directly or indirectly coupled to the interconnect 110.

[0055] In an example implementation, the plurality of memories may include a read-only memory 206 (ROM 206), a static random access memory 208 (SRAM 208), and a flash memory 210. The plurality of peripheral devices 250 may include an alarm handler 204, an advanced encryption standard (AES) engine 212 (AES engine 212), a hash-based message authentication code (HMAC) engine 214 (HMAC engine 214), a serial peripheral interface (SPI) device 230 (SPI device 230), and a flash controller 216. The plurality of peripheral devices 250 may also include a universal asynchronous receiver / transmitter (UART) unit 218 (UART unit 218), a general purpose input / output (GPIO) interface 220 (GPIO interface 220), a pin multiplexer 222 (pin mux 222), and a board controller 224. The plurality of peripheral devices 250 may also include a random number generator 232 (RNG 232) and a timer 234. In addition, the peripheral devices 250 may include any memory, such as Figure 2 As shown. Figure 2 Although certain examples of memory and other peripherals 250 are depicted in or described herein, a given implementation of secure circuit system 106 may include more, fewer, and / or different instances of processors, controllers, memories, modules, or peripherals, including copies thereof.

[0056] The circuit components shown may operate synchronously based on one or more clock signals. Figure 2 106. Although not shown in the drawings, the safety circuit system 106 may include at least one clock generator to generate a clock signal, or may include a reset circuit system to reset one or more individual components independently of each other, jointly reset multiple components, or reset the entire IC chip. Alternatively, the safety circuit system 106 may receive at least one clock signal or reset signal from a source external to the safety circuit 106, which may or may not be on a separate chip. One or more separate peripheral devices 250 may operate in corresponding independent clock domains. For example, an input / output (I / O) peripheral device may be synchronized with a clock local to a corresponding I / O device or channel. Peripherals in different clock domains may operate or communicate asynchronously relative to each other.

[0057] An example implementation of the components shown is described below. Processor 202 may be implemented as a "main," "central," or "core" processor of the safety circuit system 106. By way of example only, processor 202 may be implemented with a 32-bit, in-order reduced instruction set computing (RISC) core with a multi-stage pipeline. With, for example, RISC-V functionality, the processor may implement M (machine) and U (user) modes. Activation of a reset pin (not shown) (e.g., by deactivation of an active low reset pin) causes processor 202 to exit reset and begin executing code at its reset vector. The reset vector may begin in ROM 206, which verifies the code therein before jumping to an emulated embedded flash memory (e-flash). In other words, it is expected that the code has been instantiated into the e-flash before the reset is released. In some cases, resets throughout the safety circuit system 106 may be set to asynchronous active low to support interoperability between various circuit components, according to compatibility specifications. Alarm handler 204 may generate resets as a safety countermeasure and through watchdog timers, etc. The reset signal may also be sent to other circuit components, such as one of the memories or one of the other peripherals 250 .

[0058] Coupled to the processor 202 is a debug module 226 (DM 226) and an interrupt controller 228 (ItC 228), either of which may be made compatible. The debug module 226 provides debug access to the processor 202. By interfacing with certain pins of the IC, the logic in the debug module 226 allows the processor 202 to enter a debug mode and provides the ability to inject code into a device (e.g., by emulating instructions) or into memory. The interrupt controller 228 may be arranged close to the processor 202. The interrupt controller 228 may receive a vector of an interrupt source from within the secure circuit system 106. The interrupt controller 228 may also assign levels and priorities to interrupts and then forward them to the processor 202 for processing.

[0059] The processor 202 may provide any desired performance level or include any internal circuit components. For example, the processor 202 may include at least one arithmetic logic unit (ALU) (e.g., including an "additional" ALU for calculating branch targets to remove latency cycles on taken conditional branches) and multiple pipeline stages. Through multiple pipeline stages, the pipeline may perform register writebacks to reduce latency cycles from loads and stores and prevent pipeline stalls in the event that a response to a load or store is available in a cycle after the request. The processor 202 may implement a single-cycle multiplier or generate an imprecise exception for an erroneous response to a store, which allows the processor to continue past the store execution without waiting for a response. Although not depicted, the specific processor 202 or the general security circuit system 106 may include an instruction cache to provide a single-cycle access time for instructions.

[0060] In the example shown, secure circuit system 106 includes three memory address spaces for instructions and data. ROM 206 is the target of processor 202 after reset release. ROM 206 contains hard-coded instructions to perform a subset of platform checks before checking the next level code. The next level code - for example, a boot loader stored in electronic flash memory - may be the first piece of code that is not hard-coded into the silicon of the device. Therefore, the next level code is signature checked for integrity to increase security. ROM 206 can perform this signature check by implementing an RSA check algorithm on the entire contents of the boot loader.

[0061] Flash memory 210 may be implemented as electronic flash memory for code storage. This electronic flash memory may house the boot loader mentioned above, as well as an operating system and applications on top. SPI device 230 may be used to bulk load the electronic flash memory. Debug module 226 may also be used for code loading. SRAM 208 may operate as a scratchpad SRAM that may be used for data storage (e.g., for stack and heap information) by processor 202. SRAM 208 may also store code.

[0062] The security circuit system 106 may include a set of "peripherals" or "peripherals". These peripherals 250 may be slave execution units coupled to the processor 202 via the interconnect 110. Each of these peripherals 250 may follow an interface framework that ensures compatibility with each other and with the processor 202. The compatibility scheme may specify how the processor 202 communicates with a given peripheral (e.g., using the interconnect 110), how the peripheral communicates with the chip I / O (e.g., via fixed or reusable I / O), how the peripheral communicates with the processor 202 (e.g., using interrupts), how the peripheral communicates security events (e.g., using alarm indications) to other circuit components (e.g., alarm handler 204); how the peripheral communicates with other peripherals - for example, via at least one register, synchronously or asynchronously; or a combination thereof. The depicted peripherals 250 may include peripherals relative to alarm-related functions provided by the alarm handler 204, relative to the processor 202, relative to one or more memories, and relative to the chip I / O, etc. Therefore, memories may also include peripherals 250 relative to each other or other depicted circuit components.

[0063] The circuit or chip I / O peripherals include a pin multiplexer 222 and a pad controller 224. The pin multiplexer 222 provides signaling routing between at least a portion of the peripherals 250 and available reusable I / O nodes of the security circuit system 106 (e.g., chip pins that integrate various components or interfaces to other parts of the SoC). The pad controller 224 manages the control or pad properties of each circuit (e.g., chip's) external I / O, such as drive strength, technology, and pull-up versus pull-down. The pin multiplexer 222 and pad controller 224 are themselves peripherals on the interconnect 110. Therefore, each can have or can be otherwise associated with at least one set of registers that provide software configurability.

[0064] The UART unit 218 can implement UART features, such as single-channel duplex UART functions. Its output and input can be configured to be connected to any circuit I / O via a pin multiplexer 222. The GPIO interface 220 creates a G-bit bidirectional communication with an external circuit system via a pin multiplexer 222, where G is a positive integer, such as 16, 32, or 64. With respect to memory I / O, the SPI device 230 can implement a firmware mode. Here, the firmware mode can enable the following features, which provide the ability to enable an external drive to send firmware upgrade code to a group of flash memory 210 for field firmware updates. The firmware mode can include addressing the memory using SPI transactions. Although not depicted, the secure circuit system 106 may include an inter-integrated circuit (I2C) host to enable commands for I2C devices. This command for I2C devices may include standard, complete, and fast modes.

[0065] Several "core security" peripherals are also described, including an encryption engine and an alarm handler 204. The AES engine 212 can provide symmetric encryption and decryption using one or more protocols and different key sizes, such as 128b, 192b, or 256b. The component can select, for example, 16 bytes of 16 bytes encrypted or decrypted using different block cipher operation modes to encrypt or decrypt the arriving data. The AES engine 212 can support electronic codebook (ECB) mode, cipher block chaining (CBC) mode, cipher feedback (CFB) mode, output feedback (OFB) mode, and counter (CTR) mode, etc. Data transfer can make the processor available, for example, keys and data materials can be passed to the cryptographic engine via register writes. Alternatively, a dedicated channel for transmitting keys and data materials can be included to reduce exposure to potentially untrusted processor activities.

[0066] The HMAC engine 214 can utilize, for example, a secure hash algorithm (SHA) SHA-256 as a hash algorithm. SHA-256 is a member of the SHA-2 family of hash algorithms, in which the digest (or hash output) is 256b in length, regardless of the data size of the input to be hashed. Data is sent to the HMAC peripheral device after declaring the start of a hash request. This resets the internal state to an initial condition, for example 32b at a time. Once the component client has sent the data, the client can indicate completion of the hash request (with an optional partial word final write). According to an example portability interface scheme, the HMAC engine 214 generates a hash result and makes it available to a register read by the requesting client. Data transfer can be made available to the processor or private to reduce exposure to potential untrusted processor activity.

[0067] HMAC is a message authentication protocol layered on top of a hash function (e.g., SHA-256), with the HMAC mixed in a secret key used for cryptographic purposes. HMAC is a special application that appends a secret key around the hash (via SHA-256) of the message in a prescribed manner (e.g., twice). To provide this functionality, a 256b key may be programmed into the circuit components before the message hashing begins. The time for authentication to complete may vary, and may be longer in latency than using native SHA-256. Again, the hash information or secret key may be made available to the processor for convenience or processing efficiency, or may be made private in some way to improve security.

[0068] The alarm handler 204 is responsible for processing and responding to alarms, including alarms provided from other peripheral devices 250. Alarms can be considered as security-sensitive interrupts, and they will be handled in a timely manner in response to perceived security threats. Unlike "standard" interrupts, alarms are not only handled by software executed on the processor 202. Alarms can trigger a first-stage request to be handled by software as a "conventional" interrupt. However, if the software cannot respond and correctly remedy the interrupt triggered by the alarm, the alarm handler 204 triggers a second-stage response. The second-stage response can include formulating security countermeasures, including terminating processes, erasing or otherwise deleting data, withdrawing power from a circuit portion, or resetting an IC chip or portion thereof. This ensures that even if the processor 202 is busy, blocked, or also attacked, the potential problem-the perceived security threat-is resolved.

[0069] Therefore, (for example, Figure 1 The alarm 112 may be implemented as an interrupt type signal or alarm indication that the alarm handler 204 receives from other peripheral devices and indicates the raising of a potential security threat. In operation, the alarm handler 204 may collect alarms from other circuit components 108 of the security circuit system 106 and convert them into interrupts that the processor 202 can address. However, if the processor 202 does not clear the interrupt, the alarm handler 204 provides a hardware response to resolve the potential security threat.

[0070] For some inter-device communications, the alarm handler 204 receives synchronous or asynchronous alarm indications from peripheral device sources that send notifications in different ways. The peripheral device 250 can generate alarms based on the functionality, knowledge, or sensed parameters of the peripheral device 250. For other inter-device communications, the alarm handler 204 performs ping tests of the alarm sources as a robust heartbeat mechanism. The ping monitor (not explicitly shown) of the alarm handler 204 requests periodic alarm responses from each alarm source to ensure that the communication channel with the alarm source is functioning properly.

[0071] The alarm handler 204 may also generate a locally-sourced hardware alarm based on a communication failure. If a differential signaling or other specified communication protocol fails with the alarm source or escalation handler (e.g., if a signal integrity check fails), a first locally-sourced alarm is generated. If the alarm source or escalation handler fails to respond to a ping request, the alarm handler 204 generates a second such alarm. In general, the alarm handler 204 may receive incoming alarms from throughout the system, classify the alarms, issue interrupts based on the classified alarms, and escalate the interrupts to hardware-based responses if the processor 202 does not clear the issued interrupts. Thus, if the processor is unable to or does not handle a security alarm, the alarm handler 204 may act—for example, as a stand-in for a security response.

[0072] In some architectures, security alarms are intended to be rare events, at least relative to "standard" interrupts. Therefore, during the design phase, a possible event can be designated as an alarm event if the event is not expected to occur frequently and the event has potential security consequences. Examples of such events are parity errors (which may indicate an attack), unauthorized actions on encryption or security-related components, and sensed values ​​(e.g., voltage or temperature) from physical sensors indicating environmental modifications, etc. The system routes the alarm through the alarm handler 204, which converts the alarm into an interrupt that the processor 202 potentially addresses. For some implementations, it is potentially desirable that the secure operating system has a protocol for handling any such interrupts caused by alarms in software. If so, the secure operating system can typically resolve the interrupt and then clear the interrupt using the alarm handler 204.

[0073] Each peripheral device 250 can present a list of individual alarms representing various potential threats to be handled. The peripheral device can transmit the alarms as alarm indications to the alarm handler 204 using a specific encoding mechanism. Figure 6 and 7 Describes a compatible communication signaling scheme for handling alarms. Figure 6 The signaling scheme involves communication between the alarm handler 204 and another peripheral device 250 that can generate an alarm. Figure 7 The signaling scheme involves the alarm handler 204 and the event handler ( Figure 2 ), the event handler may implement security countermeasures in response to an escalation command from the alarm handler 204 after appropriate escalation of the triggered alarm.

[0074] The secure circuit system 106 may also include RNG 232. Typically, randomness can contribute to security functions by providing execution changes that can prevent attackers from predicting a good time to launch an attack. For example, random numbers can provide secret materials for identity and encryption purposes. RNG 232 can be implanted in algorithm calculations to obscure sensitive data values. Typically, RNG 232 provides better performance because its digital generation is becoming more and more truly random, and to this extent it can also resist attacks. RNG 232 can be implemented as a "real" RNG (TRNG), which can involve a design with an analog part to take advantage of some non-deterministic physical events or processes. Example TRNG designs rely on metastable states, electronic noise, timing variations, thermal noise, and quantum variations, etc. TRNG filters one or more result variables and sends them to an entropy pool that the device can sample for the current random function between timings. In some cases, the interface of the entropy pool may include a read request for available random bits. The TRNG interface indicates how many bits are available, and the requested peripheral device or software can read the range bits from the pool. Attempting to read an unavailable entropy bit may trigger an interrupt or alarm.

[0075] Two other peripherals 250 include a timer 234 and a flash controller 216, the latter described in the following paragraphs. The timer 234 may, for example, support accurate performance of the processor 202. The timer 234 is formed of a plurality of bits (e.g., 64 bits) and operates as a free-running timer with a guaranteed frequency within a certain percentage. Another timer (not explicitly shown) may act as a watchdog timer to support the processor 202 in the event that the processor becomes unresponsive. Unresponsiveness may be caused by, for example, wedged exploit code and security attacks.

[0076] Flash controller 216 controls flash memory 210, which can be used for code and data storage. The main read path for this data can be in the standard memory address space. However, writes to this address space can be ignored because flash memory is not written in a standard way. Instead, in order to write to flash memory 210, software interacts with flash controller 216. Flash functions can include three main commands: read, erase, and program. Read commands can be standardized and can use the chip memory address space. Erase commands are executed at the page level, where the page size can be parameterized by flash controller 216. After receiving an erase request, flash controller 216 erases the contents of the target page, which presents the data in a "1" state (e.g., 0xFFFFFFFF per word). Afterwards, software can program individual words to any value. Flash bits do not return to a "1" state without another erase, so future contents can be effectively changed by the AND of the current contents and the written value. Erase and program commands are relatively slow. Typical erase times are measured in milliseconds, and programming times are in the microsecond range. Security is also a concern because secret data can be stored in flash memory 210. Flash controller 216 may therefore provide some memory protection.

[0077] Figure 2 , which has a particular set of circuit elements. However, a given security circuit system 106 may have more, fewer, or different circuit components. The circuit components may also be interconnected differently or operate in ways other than those example ways described above. In addition, some circuit components may be omitted, while other circuit components may be implemented in multiple instances. For example, the alarm handler 204 may be repeated or distributed, or multiple AES encryption engines 212 may be present in some security circuit systems 106. In addition, the GPIO interface 220 may be omitted from the peripheral device 250 of the security circuit system 106 for the IC chip, where the security circuit system 106 forms only one of dozens of cores.

[0078] Example scenarios, techniques, and hardware for compatibility of peripheral devices with safety circuit systems

[0079] (For example, Figure 1 and 2 The safety circuit system 106 may include compatible circuit components, including a peripheral device 250. The document describes an example method for making peripheral devices compatible. Each peripheral device 250 may comply with a compatibility specification of the safety circuit system 106. By complying with the compatibility specification that defines at least one interface scheme or communication protocol, the peripheral device 250 is implemented to have at least one interface that produces consistent and expected interactions between the peripheral device 250 and the other peripheral devices. This improves the predictability and determinism of communications and reduces the time involved in designing and testing the safety circuit system.

[0080] Figure 3 An example peripheral device 250 is illustrated at 300, which includes at least one interface 302 to support compatibility with other circuit components. More generally, Figure 3 The system includes an interconnect 110, a processor 202 coupled to the interconnect 110, and a plurality of peripherals coupled to the interconnect 110. Thus, the plurality of peripherals may be coupled to the processor 202 via at least the interconnect 110. However, each peripheral 250 may also be coupled to the processor 202 directly or otherwise without using the interconnect 110. Figure 3 P peripheral devices 250 - 1 , 250 - 2 , . . . , 250 -P are explicitly depicted, where P represents a positive integer.

[0081] In an example implementation, each peripheral device 250 includes at least one interface 302 that enables the peripheral device 250 to comply with a communication framework that provides a deterministic communication framework for interoperating peripheral devices. For example, the interface 302 or communication interface 302 can enable the peripheral device 250 to implement at least one communication protocol 320. The interface 302 includes at least one interconnect interface 304, at least one device-to-device interface 306, and at least another interface 308. These interfaces are described below. As shown, the peripheral device 250 also includes at least one register interface 310 and at least one security function module 312. Typically, the interface 302 enables the peripheral device 250 to comply with a common framework to interact with the processor 202 and other peripheral devices of the plurality of peripheral devices 250-1 ... 250-P.

[0082] Register interface 310 includes one or more registers or register entries. For example, each register entry can be used for communication to and from peripheral device 250 (e.g., communication to and from peripheral device 250). For example, processor 202 or another peripheral device can set or clear a register entry, or can load a register entry with a value to communicate with peripheral device 250. Conversely, peripheral device 250 can change the value of a register entry to communicate with processor 202 or another peripheral device. To enable such communication, peripheral device 250 can expose at least a portion of register interface 310 to processor 202 or another peripheral device. For example, peripheral device 250 can provide processor access to clear an interrupt status indication, as described below with reference to Figures 5-2 to 5-4 as described.

[0083] Typically, a block of registers may be used to communicate with the rest of the peripheral logic to manage configuration and status communications, such as with software. In some cases, control and status registers (CSRs) may be used to implement register interface 310. CSRs provide a set of registers within peripheral device 250 that are addressable by at least local host processor 202 via a circuit-wide or chip-wide address map. CSRs may be standardized to enhance software consistency and promote circuit reuse and documentation consistency. Figure 5-1 and 5-2 Example aspects of register interface 310 are described.

[0084] The security functions module 312 implements security-related functions of the peripheral device 250. Security-related functions include core or primary security functions and supporting or secondary security functions. Core security functions include, for example, alarm handling, cryptographic operations (including encryption and decryption), random number generation, and secure data storage (including storage and access to secret data (e.g., key management), etc. Support security functions include functions that enable or facilitate the execution of core functions. Examples of support security functions include memory storage, memory control, timing, circuit and chip I / O control, environmental sensors, bus hosting, etc.

[0085] In general, the interface 302 or any specific example interface (e.g., the interconnect interface 304, the device-to-device interface 306, or another interface 308) can establish at least one register for the register interface 310 to enable corresponding interface communication capabilities or features. With respect to the interconnect interface 304, the interconnect interface 304 implements a communication interface that is coupled to the interconnect 110 to enable, for example, a connection between the peripheral device 250 and the processor 202 that complies with a common framework. Since the peripheral device 250 and the processor 202 are compatible with the same common framework, device-processor communication in both directions can be standardized and predictable. The interconnect interface 304 can operate across the interconnect 110, can use at least one register of the register interface 310, can use a separate bus or independent wires, and some combination thereof, etc. In operation, the peripheral device 250 can use the interconnect interface 304 to participate in at least one interconnect communication 314. Additionally or alternatively, the peripheral device 250 can use the interconnect interface 304 to communicate with another peripheral device via the interconnect 110.

[0086] The inter-device interface 306 implements a communication interface between the peripheral device 250 and one or more other peripheral devices that comply with a common framework. Since the peripheral device 250 and each other peripheral device are compatible with the same common framework, device-device communication in both directions can be standardized and predictable. The inter-device interface 306 can use at least one register of the register interface 310, can use a bus dedicated to the peripheral device, can use one or more independent wires extending between two peripheral devices, and some combination thereof, etc.

[0087] In operation, the peripheral device 250 can use the inter-device interface 306 to participate in at least one inter-device communication 316. In some implementations, the peripheral device 250 can communicate "directly" with another peripheral device by bypassing the interconnect 110 to communicate with the other peripheral device. In addition, by establishing and adhering to the inter-device communication scheme, consistency and determinism of communication between two or more devices is promoted. Therefore, designers can focus on implementing the intended safety-related functions of the safety function module 312, rather than spending time and resources tracking and reviewing multiple ad hoc communication mechanisms.

[0088] Another interface 308 implements a communication interface between peripheral device 250 and another circuit component that complies with the common framework. Since peripheral device 250 and other circuit components are compatible with the same common framework, peripheral device signaling in both directions can be standardized and predictable. An example of another interface 308 is a chip I / O interface for communicating information with the outside. If the interrupt is not fully communicated through interconnect 110, another example of another interface 308 is an interrupt interface. Another example of another interface 308 is a clock interface. In some cases, safety circuit system 106 (not in Figure 3 The peripheral device 250 may include a primary system clock and one or more secondary system clocks (individually indicated in the figure). The clock interface may utilize at least selected portions of the primary system clock and the secondary system clock for communication timing and general functions. The clock interface may operate according to a clock scheme of the security circuit system 106, and the design code of the peripheral device 250 may specify a clock associated with the peripheral device 250. In operation, the peripheral device 250 may use the other interface 308 to conduct at least one other communication 318 with another circuit component (such as an I / O circuit system or a clock tree).

[0089] Figure 4 An example method 400 for analyzing a peripheral device design to ensure that a compatible goal is met is illustrated. In an example implementation, the method 400 uses an interface specification 402, which may include an interconnection scheme 404, an inter-device scheme 406, or another scheme 408 (including each scheme). The interface specification 402 corresponds to ( Figure 3) interface 302. Interconnection scheme 404 corresponds to interconnection interface 304, inter-device scheme 406 corresponds to inter-device interface 306, and another scheme 408 corresponds to another interface 308. These schemes may additionally or alternatively include local or chip-level I / O schemes, interrupt schemes, clock schemes, and the like.

[0090] Thus, the interface specification 402 may establish rules, protocols, attributes, options, capabilities, etc. for the interface 302. Similarly, each of the interconnection scheme 404, the inter-device scheme 406, and the other schemes 408 may establish rules, protocols, attributes, options, capabilities, etc. for the interconnection interface 304, the inter-device interface 306, and the other interfaces 308, respectively. During design time, the designer develops each peripheral device 250 to comply with each relevant scheme of the interface specification 402. For example, the inter-device scheme 406 may establish a format for inter-device signaling of the interconnect 110 that defines bypassing the security circuit system 106. By doing so, compatible peripheral devices 250 may be produced, which enhances interoperability and reduces design and development time as well as testing and debugging efforts. For example, a peripheral device 250 may transmit a signal (e.g., an inter-device signal) to another peripheral device using a circuit system derived from the attributes specified by the design code of the peripheral device.

[0091] In an example method, the compatibility analysis module 410 may perform an analysis 414 of the design code to check compatibility. The designer generates the peripheral device design code 412 with reference to the interface specification 402. Therefore, the peripheral device design code 412 meets the compatibility goal by complying with the interface specification 402. The peripheral device design code 412 may be implemented at least in part using, for example, a configuration file. The peripheral device design code 412 may include one or more instructions for processor-device signaling 418 (e.g., defining aspects of the interconnect communication 314 between the peripheral device 250 and the processor 202) and one or more instructions for inter-device signaling 420 (e.g., defining aspects of the inter-device communication 316 between the peripheral device 250 and another peripheral device), etc. The one or more instructions for inter-device signaling 420 may, for example, relate to signals exchanged between two or more peripheral devices, including the interconnect 110 that does not use the safety circuit system 106. These instructions may follow rules and guidelines for registers, signal naming, data types and timing of these signals, etc.

[0092] The description in the peripheral device design code 412 results in circuit components in the safety circuit system 106. For example, with respect to (e.g. Figure 3The device-to-device interface 306 of the corresponding peripheral device 250 can be coupled to at least one wire extending to another peripheral device to enable device-to-device signaling based on the attributes included in the design code 412 for it. By specifying the device-to-device signaling 420 in the design code 412, interoperability and communication certainty are increased. The interface specification 402 or the configuration file of the design code 412 can indicate mandatory peripheral features and optional peripheral features in a given compatibility framework. Therefore, in some cases, a compatible design code may include mandatory parts and optional parts. Generally, the design code 412 can be formatted according to any IC design or configuration platform. Examples include Verilog, Python, Hjson, etc. The example configuration file format is explained below.

[0093] In operation, the compatibility analysis module 410 receives peripheral device design code 412. With reference to the interface specification 402, the compatibility analysis module 410 performs an analysis 414 to check whether the peripheral device design code 412 conforms to the specified common framework. The compatibility analysis module 410 can compare the peripheral device design code 412 with one or more of the interconnect scheme 404, the inter-device scheme 406, or another scheme 408 to check whether the code meets the specifications of each scheme. Any of these schemes can include specifications related to interrupts and register usage, etc. Based on the analysis 414, the compatibility analysis module 410 generates a compatibility report 416.

[0094] The compatibility report 416 indicates whether the peripheral device design code 412 passes the analysis 414 by satisfying the criteria of the interface specification 402. If not, the compatibility analysis module 410 may include a list of "violations" in the compatibility report 416. Each violation may include a reference to a portion of the code that caused a failure indication or a reference to a portion of the interface specification 402 that was violated. Although the interface specification 402, the compatibility analysis module 410, and the peripheral device design code 412 may be described with respect to an example safety circuit system environment, the interface specification 402, the compatibility analysis module 410, or the peripheral device design code 412 may be implemented in other environments. Therefore, the compatibility report 416 may cover the analysis of general circuit designs.

[0095] Figure 5-1 An example peripheral device 250 including a register interface 310 and example communication signals is illustrated at 500-1. Figure 5-1 In the figures, generally but by way of example only, mandatory communication channels or signals are depicted with solid lines and optional communication channels or signals are depicted with dashed lines. However, in other cases, different channels or signals may be mandatory or optional. Furthermore, solid or dashed lines in other figures do not necessarily indicate a requirement or lack of a requirement, respectively, under a given interface specification.

[0096] In an example implementation, various signals may be specified as part of a compatibility framework for the peripheral device 250 to comply with. Starting from the upper left corner, bidirectional signaling 502-1 using the interconnect 110 is depicted, wherein the peripheral device 250 is used as a device (e.g., as a follower) relative to the interconnect 110. Below it, the peripheral device 250 is shown, which receives at least one clock signal 504 and at least one development mode signal 505. The development mode signal 505 represents an indication of what mode the safety circuit system 106 of the peripheral device 250 or the entire SOC is currently operating in. In other words, there may be multiple operating modes. With two example modes, the multiple modes may include a development mode and a production mode. For example, a mode indication may determine how software errors are handled. Other modes may enable safety features that communicate full lifecycle mode states to the peripheral device.

[0097] Peripheral device 250 may also generate or output at least one interrupt signal 506 or at least one alarm signal 508. In addition, bidirectional signaling 502-2 using interconnect 110 is depicted with peripheral device 250 acting as a master (e.g., as a leader) relative to interconnect 110. Peripheral device 250 may further engage in bidirectional signaling 507 with GPIO interface 220 or other chip I / O circuitry. With respect to register interface 310, at least one output signal 509-1 is labeled as a register to hardware (Reg2Hw) signal. On the other hand, at least one input signal 509-2 is labeled as a hardware to register (Hw2Reg) signal. Further described below Figure 5-1 These signals are depicted in Figure 5-3 Examples of incoming and outgoing register signals are described in the context of interrupts. However, before describing interrupt register signals, refer to Figure 5-2 Describes an example interrupt register entry.

[0098] Typically, in some implementations, certain features are considered mandatory, while other features are considered optional. However, these mandatory and optional categories may differ between different implementations. With compatible design, these two categories can be assigned by feature so that each peripheral 250 interoperates appropriately with other peripherals. Next, an example assignment between mandatory and optional categories is described. First, the clock specification is mandatory. Each peripheral specifies its primary functional clock and any other clocks to be used. The primary clock is the main clock that drives the interconnect through which the peripheral communicates. The clock section also lists the available clocks. If you want to use other clocks, you can specify them. Secondly, the bus device (or follower) interface is mandatory. Each peripheral 250 can include one or more registers; therefore, each such peripheral 250 is configured as a device on the chip bus or other interconnect 110. Third, one or more registers are mandatory. Therefore, each peripheral 250 defines a register set in a specified register format. Based on the design code of the peripheral 250, registers can be automatically generated by instantiating the relevant hardware. Corresponding software or documentation can also be created.

[0099] Fourth, the bus master (or boot) interface is optional. If included, the peripheral device 250 can act as a bus master in some cases, even if the simplicity of the overall chip can be increased by making the processor the main host. By way of example, a direct memory access unit (DMA unit) type peripheral device 250 can instantiate a bus master interface. Fifth, the specification of available I / O is optional. If the peripheral device 250 is to be connected to a dedicated or multiplexed I / O pin, the peripheral device 250 can indicate its peripheral inputs and outputs that can be used for chip I / O. Sixth, interrupts are optional. The peripheral device can generate a signal for interrupting the main processor. These interrupts are specified using a list of corresponding signals. Each specified interrupt results in a single line or bundled output sent to the processor 202 to be collected as part of its interrupt vector input. Seventh, alarms are also optional. The peripheral device can generate a signal indicating a potential security threat. These alarms are also specified using a signal list. Each specified alarm results in a complementary signal pair sent to the alarm handler 204. Eighth, inter-device signals are optional. Peripheral devices can specify separate signals connected to other peripheral devices, referred to here as inter-device signals. In other implementations, different features may be designated as mandatory or optional in various ways. In other implementations, features may not be designated as mandatory versus optional, or different categories may be used to designate them.

[0100] Figure 5-2An example register interface 310 with multiple interrupt entries is illustrated at 500-2. Typically, the register interface 310 includes multiple register entries. As shown for interrupt-related aspects, the register interface 310 includes multiple interrupt entries 510-1, 510-2, ..., 510-I, where I represents a positive integer. The number I of multiple interrupt entries 510-1 ... 510-I can vary for each peripheral device 250 and from design to design.

[0101] In an example implementation, each interrupt entry 510 includes three indications or registers: an interrupt enable indication 512, an interrupt status indication 514, and an interrupt test register 516. Each indication has at least one bit. By way of example, if each indication is one bit and the register interface 310 includes 16 interrupt entries 510-1 ... 510-I (e.g., I = 16), the register interface 310 includes 48 bits (3×16=48) to handle the interrupt of the peripheral device 250. The register interface 310 may include other entries.

[0102] In operation, the interrupt enable indication 512 determines whether the corresponding interrupt is activated for use. In some cases, the processor 202 can set the enable indication; in other cases, the peripheral device 250 or both can set the enable indication. If the interrupt is triggered, the interrupt status indication 514 is valid, and if the interrupt is cleared, the interrupt status indication 514 is inactive. The processor 202 can use the interrupt test register 516 to test the interrupt; for example, the processor 202 can trigger the register to trigger the interrupt for testing purposes. Reference Figure 5-2 The interrupt hardware and Figure 5-3 These indications are further described in Interrupt Signaling.

[0103] Figure 5-3 An example interrupt entry 510 (or interrupt register 510) is illustrated at 500-3. Interrupt entry 510 includes an interrupt enable indication 512, an interrupt status indication 514, and an interrupt test register 516. For example, the signaling on the left side of interrupt entry 510 (as depicted) represents signals that can be transmitted through interconnect 110. Each of indications or registers 512, 514, and 516 receives two signals wd and we from, for example, processor 202. The we signal represents write enable, while the wd signal represents write data. Processor 202 can read the current state or condition of interrupt status indication 514 represented by the qs signal. (For example, Figure 5-1 The peripheral device 250 may associate the d input of the interrupt status indication 514 with a “1” (eg, high) or a valid voltage level.

[0104] For the test mode, the processor 202 drives the wd and we signals to be valid into the interrupt test register 516 to trigger the interrupt test. The interrupt test register 516 outputs the two valid signals as q and qe signals, which are coupled to the two inputs of the AND gate 534. When both signals are valid, the AND gate 534 provides a valid value to the lower input of the OR gate 536. Based on at least one signal being valid, the OR gate 536 drives the de input of the interrupt status indication 514 to be valid. This presents the current state of the interrupt status indication 514 as set. The processor 202 accesses this state via the qs signal.

[0105] For the normal or operating mode, the peripheral device 250 detects an event corresponding to an interrupt and drives the interrupt event signal (Interrupt_Event) at the upper input of the OR gate 536 to high. Based on at least one signal being valid, the OR gate 536 drives the de input of the interrupt status indication 514 to be valid. This presents the current state of the interrupt status indication 514 as being set. The set state permeates through the circuit system (not explicitly shown) of the interrupt status indication 514 and is output as a valid q signal of the interrupt status indication 514. The valid state signal is coupled to the upper input of the AND gate 532.

[0106] At the same time, the processor 202 can also drive the wd and we signals to be valid entry interrupt enable indication 512. If so, the interrupt enable indication 512 drives its output q signal to be valid. The valid signal is propagated to the upper input of the AND gate 532. When both inputs of the AND gate 532 are valid, the AND gate 532 drives the output of the interrupt entry 510 to be valid. Therefore, the peripheral device 250 drives the interrupt signal 506 (Interrupt_Signal) to be valid in response to the detection of the interrupt event. The valid interrupt signal 506 is routed or coupled to the interrupt handling hardware of the processor 202.

[0107] Although specific gates and certain signaling relationships are described above for the example interrupt entry 510, the interrupt entry 510 (or another register entry of the register interface 310) may be implemented in alternative ways. For example, the peripheral device 250 may control a register enable. In addition, the wd signal may have multiple bits. In addition, signaling to and from the peripheral device 250 may be performed via the interconnect 110 or through another (e.g., direct, exclusive, or peripheral-only) signaling path with another peripheral device 250.

[0108] Figure 5-4An example timing diagram 500-4 for handling interrupts between a peripheral device 250 and a processor 202 is illustrated. The timing diagram 500-4 includes a clock signal (Clock) extending from time slots 0 to 13 across 14 cycles or half a clock cycle. Also refer to Figure 5-3 , the interrupt enable signal (Interrupt_Enable (we signal enters the interrupt enable indication 512)) is active at a high level during the entire time slot 0 to 13. Around time slot 2 or 3, the peripheral device 250 detects an event that triggers an interrupt. The peripheral device 250 drives the interrupt event signal (Interrupt_Event) to be active at time slot 3.

[0109] During, for example, a time slot, the interrupt state (Interrupt_State) of the interrupt state indication 514 becomes valid. As shown, this signal goes high during time slot 4, and this value can be read by the processor 202 (as the qs signal). Assuming that the interrupt enable indication 512 is also valid, ( Figure 5-3 The AND gate 532 of SW_WRITE_ON drives the interrupt signal 506 (Interrupt_Signal) to high active during the same time slot 4. In response to the active interrupt signal, the software operating on the processor 202 handles the interrupt over a certain number of time slots. After the interrupt is handled, the software can clear the interrupt status in the interrupt status indication 514. The timing diagram 500-4 depicts the software clearing the interrupt with the signal (SW WRITE TO CLEAR) during time slot 8. Therefore, the interrupt status, interrupt signal, and interrupt clear signal become low active at the 9th time slot.

[0110] Next, various example implementations of different peripheral features are described. First, multiple features are briefly described at a relatively high level. These features include timing, reset, bus device docking, bus host docking, I / O paths, I / O multiplexing, interrupts, alarms, and inter-device signaling. Secondly, after presenting example configuration files and corresponding documents, several features are described at a relatively low level and in more detail. These features include configuration description (or peripheral device encoding), interrupt handling, alarm handling, and inter-device signal handling. Various examples, if implemented, can be implemented individually, jointly, and in whole or in part, etc. Various examples can be further modified in various ways.

[0111] Regarding timing, each peripheral defines at least one clock: the primary clock. This is defined in the configuration file as "clock_primary" and is set to one of the known clock names. This primary clock is defined as the primary clock used to clock the bus devices, to indicate to the top level if the asynchronous handling of the bus interface is to be used. Peripherals can also request other clocks for internal use. These create asynchronous clock domains in the peripheral that are handled by the common framework. Other clocks are defined under "other_clock_list" in the configuration file.

[0112] With respect to reset, the peripheral decoding may specify the reset scheme. Alternatively, no additional information may be provided to indicate the reset scheme for a given peripheral. Alternatively, a default condition may be established whereby each clock carries its associated reset pin for that clock domain. In some cases, the reset in a design is configured as asynchronous active-low. If so, special care is applied to security-sensitive storage elements. For asynchronous active-low reset, the assertion of the reset is asynchronous to any clock. However, deassertion is synchronous to the clock of the associated storage element. Secure storage elements may "leak" sensitive state content, so storage elements should be handled with care regardless of the reset method. In this case, "careful handling" may involve synchronously - some time after a chip-wide reset - resetting their values ​​to values ​​that are randomized so that the Hamming distance between the register value and all zeros cannot yield valuable information to an attacker. Asynchronous active-low may require slightly more area and more implementation planning, but it is more common than synchronous active-high and therefore more familiar to many designers. Synchronous active-high, on the other hand, is slightly more efficient, but it involves using a clock edge to take effect.

[0113] With respect to bus device interface (e.g., as a bus follower), each peripheral specifies the type of bus operation using the "bus_device" keyword. For example, the peripheral code may specify TileLink-Uncached-Lite (TL-UL) as its interface to the interconnect 110 or to the chip-wide framework. In some cases, the address mapping of a peripheral is not determined by the peripheral itself or its configuration file. Alternatively, a higher-level full-chip configuration file may assign address ranges to each of the included bus peripherals.

[0114] With respect to the bus master interface (e.g., acting as a bus leader), each peripheral device has the option to declare itself as a bus master, at least temporarily or on demand. This capability is included in the configuration file with the "bus_host" keyword. If the peripheral device does not have this feature, the configuration file may indicate so (e.g., via an empty string). If the peripheral device has this feature, the bus master protocol name is included in the keyword. To improve compatibility, each bus master can use the same clock as the defined primary master clock. In some cases, a host identifier or identification (ID) (e.g., four bits) is provided for each bus master to distinguish between hosts within the system. This is enforced by the framework to ensure uniqueness of each host.

[0115] Regarding I / O availability, each peripheral can specify signals that are available for chip I / O (e.g., input, output, or inout). The framework determines for each signal whether the signal is routed directly to a dedicated chip pin or multiplexed with signals from other peripherals before reaching the chip pin. Available I / O for each peripheral can be specified with configuration file entries for "available_input_list", "available_output_list", and "available_inout_list". However, any of these entries can be skipped or can contain an empty list "[]". If not empty, any of these file entries can contain a comma-delimited list of signal names. In some cases, items on the input list of the form "name" induce peripheral inputs of the form "cio_name_i". Items on the output list of the form "name" induce peripheral outputs of the form "cio_name_o" as well as output enables "cio_name_en_o". Items in the inout list of the form "name" induce all three.

[0116] Regarding multiplexing chip I / O and pad control, in the top-level chip framework, a pin multiplexing unit (pinmux) can be instantiated. The pin multiplexing unit provides flexible allocation to / from peripheral I / O and chip pin I / O. Compatible peripherals do not need to specify whether their available I / O is hardwired to chip I / O or can be used for multiplexing. Alternatively, this specification is completed in a higher-level configuration file (e.g., Hjson configuration file). In addition, peripheral logic does not perform full pad control because the pad controller device performs this function. The pad controller device can provide software configuration control of pad drive strength, pin mapping, and pad type (e.g., push / pull, open drain, etc.).

[0117] Regarding interrupts, each peripheral can designate one or more output signals as interrupts destined for the local host processor. These interrupt signals are non-safety critical signals (e.g., alarm related) and are sent to the processor for handling using its interrupt service routine. The peripheral design code lists its interrupt set in the configuration file using the "interrupt_list" attribute. Each item of the form "name" in the interrupt list expects a module output named "intr_name_o".

[0118] Regarding alarms, each peripheral device can designate one or more output signals as safety-critical alarms to a hardware alarm handler device. These alarm signals are implemented as differential signals to avoid creating a single point of failure. The peripheral device transmits the alarm signal to the alarm handler to be sent to the processor for first-line defense handling. If the processor cannot resolve the alarm, the alarm handler provides a hardware safety response. The peripheral device design code uses the "alert_list" attribute in the configuration file to list its alarm collection. For each alarm in the safety circuit system, a corresponding set of signals is generated in the alarm handler to perform communication between the alarm transmitter and the alarm handler device of a given peripheral device. Refer to the following Figure 6 Example communication signaling to accommodate alerts is described below with reference to Figure 7 Example communication signaling for handling escalated alerts is described.

[0119] With respect to inter-device signaling, a peripheral device may generate, transmit, receive, or process signals exchanged between at least two peripheral devices. These inter-device signals may extend beyond interrupts and alarms. The peripheral device design code lists its set of inter-device signals in a configuration file using the "inter_signal_list" attribute. The peripheral device may define the type of each specified inter-device signal. Logical or physical connections between two or more peripheral devices may be defined in a higher-level (e.g., top-level) configuration file.

[0120] At least a portion of the peripheral design code 412 can be implemented as a configuration description. In some implementations, the configuration file is prepared in HJSON or conforms to HJSON. The configuration file can describe the peripheral 250, including the registers of the register interface 310. An example configuration file is presented below. The example includes mandatory and optional categories, as shown in the comments; nevertheless, other implementations may have one or the other category (but not both), or may not have categories. In this example, the name of the peripheral 250 is "uart". However, other configuration fields are provided as an explanation and are not necessarily consistent with the functionality of the UART peripheral. In other words, some configuration fields are shown in the example configuration file below for enlightenment purposes.

[0121]

[0122]

[0123] The example configuration file above corresponds to the example document format output presented below:

[0124] Primary Clock:clk_fixed

[0125] Other Clocks:clk,clk_lowpower

[0126] Interconnect Device Interface:tlul

[0127] Interconnect Host Interface:none

[0128] Peripheral Pins available for Chip-Level I / O:

[0129] Pin Name direction describe

[0130] tx output transmission bit

[0131] rx input receive bit

[0132] Interrupt:

[0133] Intrpt Name describe

[0134] tx_watermark Raised if the transmit FIFO exceeds the high water mark

[0135] rx_watermark Raised if the receive FIFO exceeds the high water mark

[0136] tx_overflow Raised if the transmit FIFO overflows

[0137] rx_overflow Raised if the receive FIFO overflows

[0138] rx_frame_err Raised if a framing error is detected while receiving

[0139] rx_break_err Raised if a break condition is detected while receiving

[0140] rx_timeout is raised if the receiver does not receive any characters for a programmable period of time.

[0141] rx_parity_err Raised if the receiver detects a parity error

[0142] Security Alert:

[0143] Alert Name describe

[0144] uart_breach Someone attacked the UART device

[0145] uart_frozen UART line is frozen and may be attacked

[0146] An example method of interrupt handling is further described herein. In some implementations, an interrupt has a generic name, a hardware interface, and a software interface. An interrupt is a latched indication of a defined peripheral event that has occurred but has not yet been addressed by the local host processor. An interrupt is sent to the processor as a high-level active level interrupt (as opposed to an edge interrupt). The triggering event can be an edge or level and high-level active or low-level active, as defined by the associated peripheral device. For example, a GPIO device can interpret a rising or falling edge of one of its input bits as an interrupt event. Latching of events can be performed by an automatically generated register file, as described below. Clearing of events is performed by a processor write in response to completion of event handling. Also refer to above Figure 5-2 and 5-3 An example interrupt entry 510 of the register interface 310 is described. Figure 5-4 Example waveforms showing the timing of events occurring, the corresponding latching of interrupt values, and the processor clearing the interrupt are described.

[0147] With respect to interrupts for a given peripheral, the peripheral may generate a separate interrupt for each event, but send them together as a bundle to the local processor's interrupt module. The "disambiguation" or determination of which interrupt woke the handler may be performed in the processor in the interrupt handler. In an alternative model, each peripheral sends only one interrupt at a time, and the processor may disambiguate by querying the peripheral to determine which interrupt was triggered. To define one or more interrupts, the peripheral design code may specify them. For example, the configuration file described above specifies the relevant properties of the interrupt. Circuit generation tools may be used to generate additional design aspects based on the configuration file described in the above example.

[0148] With respect to register creation, for each peripheral, three registers are automatically created to manage each interrupt for that peripheral (e.g., as defined in the "interrupt_list" section of the Hjson file). However, alternative default register formats may be implemented using different register purposes or different numbers of registers instead. Additionally, the automatic generation may be overridden. Each interrupt has a field bit for each of the three registers. The three registers are the INTR_STATE register, the INTR_ENABLE register, and the INTR_TEST register, which are represented by an interrupt status indication 514, an interrupt enable indication 512, and an interrupt test register 516 ( Figure 5-2 and 5-3 The interrupt registers can be placed on top of the peripheral device address map by automatic generation tools.

[0149] The INTR_ENABLE register can be read and written by the processor (rw), one bit per interrupt, which, when true (true), enables the interrupt of the peripheral device to be reported to the interrupt input of the processor. The INTR_STATE register can be read by the processor, and each bit can be written 1 to clear it (rw1c). Therefore, the reading of the register indicates the current state of all latched interrupts, and writing 1 to any field clears the state of the corresponding interrupt. INTR_TEST is a write-only (wo) register that allows software to test the reporting of interrupts (modulo the effect of INTR_ENABLE) by simulating the triggering of actual interrupt events, the setting of the INTR_STATE register, and the increase of the interrupt signal level output to the processor. The content of the INTR_STATE register does not need to be affected by the enable value. Instead, the INTR_STATE register shows the original state of the latched hardware interrupt event. The output interrupt signal sent to the processor is ANDed with the interrupt enable register (e.g., AND gate 532) before being sent to the processor for stimulating.

[0150] With respect to handling interrupts, the interrupts sent to the processor are active-high level interrupts of the same severity (e.g. Figure 5-3 The interrupt signal 506 can be high level active, such as Figure 5-4 Alternatively, interrupts can have different severity levels. For example, a higher priority interrupt can be implemented as a non-maskable interrupt (NMI). Figure 5-3 , three indications (eg, interrupt enable indication 512, interrupt status indication 514, and interrupt test register 516) may be implemented as software-oriented registers. Figure 5-3, the interrupt_event signal is shown arriving at the interrupt entry 510 from another portion of the peripheral device 250. Within the register file, the interrupt event triggers the setting of the associated bit in the INTR_STATE register to 1. Additionally, writing a 1 to the bit associated with this interrupt in the INTR_TEST register may set the corresponding INTR_STATE bit. The output of the INTR_STATE register becomes the output interrupt to the processor after being masked (e.g., ANDed) with the value of INTR_ENABLE.

[0151] In some cases, the handling of the ro / rw1c function of the INTR_STATE register allows software to control the clearing of the contents of INTR_STATE. Writing a 1 to the corresponding bit of INTR_STATE clears the latched value. However, if the triggering event represented by the interrupt_event signal itself is still valid, the INTR_STATE register returns true. In this example, the hardware does not have the ability to clear the latched interrupt state; the clearing is reserved for software. However, the hardware can be designed to enable this function. Interrupts sent to the processor are handled by its interrupt controller. In the interrupt controller logic, there may be another level of control for enabling, prioritizing, and enumerating multiple interrupts.

[0152] Example means of alarm handling are further described herein. In some implementations, alarms are standardized across peripheral devices for consistency. Unlike interrupts, there is no software component for alarms on the originating peripheral device, but there may be at a hardware alarm handler. At the originating peripheral device, one or more alarms may be sent from the peripheral device to the alarm handler as a bundled output. Each peripheral device may be designed to send zero or more alarms, each corresponding to a distinguishable security threat. Each alarm originates from an event internal to the corresponding peripheral device, and the peripheral device may first attempt to resolve the detected event. After the peripheral device communicates the alarm to the alarm handler, the alarm handler processes the alarm, which processing may include escalation to an escalation handler that implements security countermeasures.

[0153] Within a peripheral device, detected internal events that are active high are sent to a module within the peripheral device called an alarm transmitter module. In a given peripheral device, one alarm transmitter module is instantiated for each different alarm event type. The designer of the peripheral device determines what are different alarm events. Multiple alarms can be bundled together depending on the distinction required within the module (e.g., high priority threats vs. low level threats). The alarm transmitter module converts the alarm events into differentially encoded signal pairs, which are routed to the alarm handler hardware. Figure 6An example implementation of this alarm signaling is described.An alarm handler may be automatically generated to have sufficient alarm receiving ports to have one port corresponding to each alarm declared in the configuration files of the various included peripherals.

[0154] An example method for inter-device signal handling is further described herein. Inter-device signals can refer to individual or bundled signals that are connected to peripheral instances in the top-level design. Some peripherals can be stand-alone peripherals, such as GPIO or UART peripherals. These peripherals report interrupts to the main processor but do not need to talk to other peripherals. In contrast, some peripherals and the main processor can communicate with other peripherals directly or indirectly. For example, a flash controller sends requests for read, program, and erase operations to a flash macro.

[0155] By specifying aspects of inter-device signaling in a peripheral configuration file, consistency and interoperability are promoted. This avoids the tedious process of manually linking and testing signaling between two or more peripherals. By encoding appropriate definitions for each peripheral 250, higher-level design tools can connect each peripheral 250 appropriately to the intended other peripherals. The example configuration file provided above specifies two cases of inter-device signaling, "msg_fifo" and "suspend".

[0156] An example inter-device scheme 406 (or inter-device signaling scheme 406) is set forth below. Each aspect is described in terms of attributes, mandatory / optional categories, and descriptions. In alternative implementations, these aspects may vary. For example, mandatory and optional categories may be different or omitted, or another aspect may be added. These aspects may be used to provide inter-device signaling 420 ( Figure 4 One or more indications of ).

[0157] First, "name" is a mandatory attribute. The name attribute specifies the port name for inter-device signals. If the port type is "req_rsp" (request and response), the type indicates that the peripheral has two ports: a "name_req" port and a "name_rsp" port. Each name can contain a "_i" or "_o" suffix to specify "input" or "output", respectively.

[0158] Secondly, the "struct" attribute also has a mandatory category. The "struct" field defines the data structure of the signal. Inter-device signals can usually be bundled into a "struct" package type. This "struct" is used together with the "package" attribute to define the signal. If the inter-device signal is of logical type, the "package" field can be omitted. Therefore, the "package" attribute is optional.

[0159] Third, the "type" attribute is mandatory. There can be two types of inter-device signals in this example inter-device signaling scenario. The "req_rsp" type is a connection where one peripheral sends a request and the second peripheral returns a response. On the other hand, a "uni" type connection is a unidirectional signal. For example, a unidirectional signal can be used for broadcast signals or for signals that do not require a response.

[0160] Fourth, the "act" attribute is also mandatory. The "act" attribute is paired with the "type" attribute. The "act" attribute specifies the input / output (I / O) of the signal in the peripheral device. The "req_rsp" type can have "req (requester)" or "rsp (responder)" in the "act" field. The "uni" type can have "req" or "rcv (receiver)" in the "act" field.

[0161] Fifth, "width" is an optional attribute. If "width" is not 1 or undefined, the corresponding port is defined as a vector of "struct". Therefore, the port can be connected to multiple peripheral devices.

[0162] Figure 6 An example communication relationship 600 between an alarm receiver module 612 of an alarm handler 204 and an alarm transmitter module 622 of a peripheral device 250 is illustrated. A signaling path 632 includes at least one differential path. As shown, the signaling path 632 includes multiple pairs of wires (e.g., three pairs) to enable differential signals across three differential paths. Each pair of wires includes a positive wire and a negative wire. Modules can communicate synchronously or asynchronously through the signaling path 632. The alarm handler 204 also includes a ping monitor 604 to implement the pinging mechanism as a two-way heartbeat scheme to ensure physical and logical communication capacity.

[0163] In an example implementation, the peripheral device 250 includes at least one alarm transmitter module 622. The peripheral device 250 detects an alarm event 602. The alarm event 602 may correspond to a sensor input (e.g., a parameter sensed by a sensor), an observed activity pattern, an indication received from another component, etc. In response to the alarm event signal 602, the alarm transmitter module 622 transmits an alarm indication 652 to the alarm receiver module 612 on a first pair of wires (e.g., the upper pair as shown). In response to receiving the alarm indication 652, the alarm receiver module 612 provides a trigger alarm 662 to a controller (not shown) of the alarm handler 204. The alarm receiver module 612 also transmits an alarm confirmation signal 606 back to the alarm transmitter module 622 on a second pair of wires (e.g., the middle pair as shown) to confirm receipt of the alarm indication signal 652.

[0164] For the pinging protocol, the alarm receiver module 612 receives a ping instruction 658 from the ping monitor 604. Prompted by the ping instruction 658, the alarm receiver module 612 transmits a ping request 654 to the alarm transmitter module 622 on a third pair of wires (e.g., the lower pair as shown). To indicate that the connection to the peripheral device 250 is active and functional, the alarm transmitter module 622 transmits a ping response 656 back to the alarm receiver module 612—e.g., on the first pair of wires. For resiliency, the alarm transmitter module 622 can transmit the alarm indication 652 and the ping response 656 on the same pair of wires. This ensures that a bad actor does not cut the wires for the alarm indication 652 while leaving the wires for the ping response 656 intact. The alarm receiver module 612 receives the ping response 656 from the alarm transmitter module 622. To complete the ping protocol cycle, the alarm receiver module 612 forwards a ping okay message 660 to the ping monitor 604 in response to receipt of the ping response 656.

[0165] In some cases, at least a portion of the integrity fault circuitry 618 is coupled to or incorporated into the alarm receiver module 612. The integrity fault circuitry 618 monitors at least one pair of conductors to determine whether appropriate differential signaling is present on the differential path and whether the expected signaling pattern matches the actual signaling pattern. If not, the integrity fault circuitry 618 generates an alarm integrity fault signal 668 and provides the signal to the controller as an internal alarm of the alarm handler 204.

[0166] In some implementations, alarms are differentially encoded and signaled using a "full" handshake on the positive / negative alarm indication wires (e.g., a first pair of wires) and the positive / negative alarm confirmation wires (e.g., a second pair of wires). Employing a full handshake protocol allows the alarm signaling mechanism to be used in asynchronous clock strategies, where some peripheral devices may reside in a different clock domain than the alarm handler 204. The full handshake protocol ensures that alarm messages are properly back-pressed and that alarms are not "lost" at asynchronous boundaries due to (possibly variable) clock ratios greater than or less than 1.0. If the alarm event 602 is still true within the peripheral device 250, the local alarm indication can be repeated on the differential alarm indication line. The handshake pattern can therefore be repeated while the alarm is true. The alarm transmitter module 622 can wait, for example, for two cycles between handshakes.

[0167] In an asynchronous environment, once the initial level change on the alarm indication line has been received and synchronized with the local clock at the alarm receiver module 612, the alarm indication 652 can be propagated "immediately" to the trigger alarm signal 662. This ensures that the first occurrence of the alarm indication 652 is propagated, even if the handshake line has been manipulated to simulate back pressure. In the case of simulated back pressure, subsequent alarm indications may be back pressured; however, the ping test mechanism of the ping monitor 604 eventually detects that the bad actor has tampered with the wire.

[0168] In some implementations, to ensure that the alarm sender module 622 has not been compromised, the alarm receiver module 612 periodically (e.g., every few microseconds) "pings" or line tests the sender with a ping or heartbeat message. The ping monitor 604 can randomize the ping timing so that the occurrence of the ping request 654 message cannot be predicted. The ping timing is generated by a central LFSR-based timer within the alarm handler 204 (e.g., using the ping timer of the ping monitor 604), which randomly asserts the ping command signal 658 of a specific alarm receiver module 612.

[0169] Once the ping instruction signal 658 is asserted, the alarm receiver module 612 encodes the ping request message 654 as a level change on the ping request differential path (e.g., the third pair of wires). The alarm receiver module 612 waits until the alarm transmitter module 622 responds with a full handshake on the positive / negative alarm indication line (e.g., the first pair of wires) and the positive / negative confirmation line (e.g., the second pair of wires). Once the handshake is complete, the alarm receiver module 612 asserts a ping okay message 660. The LFSR-based timer can have a programmable ping timeout. After the programmable ping timer expires without a full handshake occurring, the ping monitor 604 asserts a "ping failure" internal alarm using an alarm ping failure signal (not shown). This timeout can be a function of the clock ratios present in the system and can be programmed accordingly at system startup.

[0170] In the relatively unlikely event that the ping request 654 conflicts with the local alarm indication 652 at the alarm sender module 622, the alarm indication 652 is blocked until the ping handshake protocol is completed. Although this approach slightly delays the transmission of the alarm indication 652, the alarm indication 652 is eventually signaled. In addition, if the alarm indication 652 is sent from the alarm sender module 622 just before the ping request 654 arrives at the alarm sender module 622, the alarm receiver module 612 treats the alarm indication 652 as a ping response. A "true" ping response is still returned just after the alarm handshake is completed, so the alarm is signaled with only a slight delay, and the alarm receiver module 612 interprets it as such. In both conflicting situations, the signaling delay is on the order of the handshake length plus a constant number of pause cycles (e.g., two sender cycles) between handshakes.

[0171] In some implementations, the integrity fault circuitry 618 monitors the differential pair for signal integrity issues. If an encoding fault is detected, the alarm receiver module 612 asserts the alarm integrity fault signal 668. This can occur at least in the following fault conditions: First, the alarm indicates that the differential path (e.g., the first pair of wires) may not be correctly encoded at the alarm receiver module 612. This can be directly marked as an integrity fault on the receiver side. Second, at the alarm transmitter module 622, the confirmation differential path (e.g., the second pair of wires) or the ping request differential path (e.g., the third pair of wires) may not be correctly encoded. Either of the latter two faults can be detected by the integrity fault circuitry (not shown) at the alarm transmitter module 622 and signaled back to the alarm receiver module 612 by causing the alarm transmitter module 622 to set the positive and negative alarm indication lines to the same value. In addition, the alarm transmitter module 622 can continuously switch the value. This implicitly triggers a signal integrity alarm at the alarm receiver module 612. Several signaling patterns can represent a fault. For example, a fault is observed if both the positive and negative lines of a differential pair have a low voltage or both have a high voltage at the same time.

[0172] Figure 7 An example communication relationship 700 is illustrated between an upgrade transmitter module 714 of an alarm handler 204 and an upgrade receiver module 724 of an upgrade handler 750, which is a type of peripheral device. As shown, a signaling path 734 includes multiple pairs of wires (e.g., two pairs) to enable differential signaling across two differential paths. Each pair of wires includes a positive wire and a negative wire. The modules can communicate across the signaling path 734 at least synchronously. In an example implementation, the upgrade handler 750 executes or at least starts a safety countermeasure based on the activation countermeasure instruction 702.

[0173] As part of the alarm handling path within the alarm handler 204, the escalation timer (not shown) provides an escalation instruction 776 to the escalation transmitter module 714. In response to receiving the escalation instruction 776, the escalation transmitter module 714 transmits an escalation command 778 on a second pair of wires (e.g., the lower pair as shown) to the escalation receiver module 724. In response to receiving the escalation command 778, the escalation receiver module 724 generates an activate countermeasure instruction 702. Thus, the escalation handler 750 at least initiates execution of the security countermeasures as described herein in response to the transmitted escalation command 778.

[0174] For the pinging protocol, the upgrade sender module 714 receives a ping instruction 658 from the ping monitor 604. Prompted by the ping instruction 658, the upgrade sender module 714 transmits a ping request 780 on the second pair of wires to the upgrade receiver module 724. To indicate that the connection to the upgrade handler 750 is valid and functional, the upgrade receiver module 724 transmits a ping response 782 back to the upgrade sender module 714 on the first pair of wires (e.g., the upper pair as shown). The upgrade sender module 714 receives the ping response 782 from the upgrade receiver module 724. To complete the ping protocol cycle, in response to the receipt of the ping response 782, the upgrade sender module 714 forwards a ping okay message 660 to the ping monitor 604.

[0175] In some cases, at least a portion of the integrity fault circuitry 618 is coupled to or incorporated into the upgrade transmitter module 714. The integrity fault circuitry 618 monitors at least one pair of conductors to determine whether appropriate differential signaling is present on the differential paths and that the expected signaling pattern matches the actual signaling pattern. If not, the integrity fault circuitry 618 generates an upgrade integrity fault signal 770 and provides the signal to a controller (not shown) of the alarm handler 204 as an internal alarm of the alarm handler 204.

[0176] In some implementations, for each of the S upgrade severities (where S represents a positive integer, such as four), the alarm handler 204 instantiates an upgrade transmitter module 714. The corresponding S upgrade handlers 750 each instantiate a corresponding upgrade receiver module 724. The upgrade signaling mechanism can be similar to the alarm signaling mechanism. However, if the upgrade handler 750 is in the same clock domain as the alarm handler 204, the upgrade signaling mechanism can be a fully synchronized protocol. In order to facilitate synchronous communication, the upgrade transmitter module 714 and the upgrade receiver module 724 can use the same clock and reset signals.

[0177] like Figure 7As shown, each transmitter-receiver pair is connected to two differential wire pairs. One pair extends from the transmitter to the receiver and the other pair extends from the receiver to the transmitter. Upon receiving the upgrade instruction signal 776 having a pulse width of K>0, the upgrade transmitter module 714 encodes the signal as a differential pulse of width (K+1) on a differential path (e.g., on the second pair of wires) for a ping request 780. The upgrade receiver module 724 decodes the message and outputs the assertion activation countermeasure 702 after a delay of one cycle (or one time slot). In addition, when the upgrade command 778 is asserted, the upgrade receiver module 724 confirms receipt of the message by continuously switching the positive / negative signal on the first pair of wires. The upgrade receiver module 724 fails to properly respond to the upgrade integrity fault signal 770 that triggers the integrity fault circuit system 618.

[0178] In addition, the differential signaling mismatch on any pair of conductors also triggers an alarm 770 for upgrading integrity faults. The mismatch on the first pair of conductors for ping response and confirmation can be directly detected at the upgrade transmitter module 714. The mismatch on the second pair of conductors for upgrading commands and ping requests is signaled back to the upgrade transmitter module 714 by the upgrade receiver module 724, which can also include integrity fault circuitry (not shown) to enable the detection of mismatch on the second pair of conductors. In order to perform the signaling, the upgrade receiver module 724 can set the positive response line and negative response line of the first pair of conductors to the same value, and switch the value in each clock cycle or time slot. This implicitly triggers the upgrade signal integrity alarm on the sender side. This reverse signaling mechanism can be used to quickly track the upgrade and use another countermeasure when the alarm handler 204 detects that a specific upgrade signaling path has been tampered with.

[0179] In some implementations, the ping test of the upgrade handler is similar to the ping test of the alarm signaling scheme. The upgrade signaling line can be pinged and / or line tested to determine whether the upgrade receiver module 724 has been tampered with. This can be achieved by asserting the input of the ping command 658 at the upgrade transmitter module 714. The ping request 780 is encoded as a single cycle pulse on the second pair of wires, which is also used for the transmission of the upgrade command 778. However, for the single cycle pulse for the ping request 780, the upgrade receiver module 724 does not decode the single cycle pulse signaling as an upgrade command. Instead, the upgrade receiver module 724 responds with a "1010" pattern on the first pair of wires to transmit a ping response 782.

[0180] In response to the ping response 782, if the expected pattern is correctly received after a waiting period, the upgrade transmitter module 714 asserts the ping okay message 660. Otherwise, the upgrade transmitter module 714 first asserts the upgrade integrity fault signal 770 to notify the controller of the alarm handler 204. Subsequently, after the programmable ping timeout is reached, the ping monitor 604 issues a "ping failure" alarm using an upgrade ping failure signal (not shown). In this case, the upgrade transmitter module 714 triggers the upgrade integrity fault signal 770 because "no ping response" and "wrong ping response" are ambiguous in this context.

[0181] In addition, in this upgrade and countermeasure scenario, the upgrade signal takes precedence over the ping message delivery. Therefore, if the upgrade instruction 776 has been asserted, the ping instruction 658 is confirmed with the ping okay message 660. If the upgrade instruction 776 becomes asserted, the ongoing ping sequence is also aborted. In some cases, the ping and upgrade response sequence is expected to start one cycle after the ping request or upgrade command is issued. Otherwise, the upgrade sender module 714 asserts the upgrade integrity fault signal 770.

[0182] Having generally described schemes, techniques, and hardware for compatibility of peripheral devices with secure circuitry, the discussion now turns to example methods.

[0183] Example methods for compatibility of peripheral devices with safety circuit systems

[0184] Reference below Figure 8 and 9 The flowchart of the present invention describes an example method. Figure 8 An example method of an apparatus for implementing compatibility of a peripheral device with a secure circuit system is illustrated by flowchart 800. Flowchart 800 includes three blocks 802-806.

[0185] At block 802, the processor communicates with a peripheral device in the plurality of peripheral devices through an interconnect based on an interconnect scheme according to a common framework for interaction between the processor and the plurality of peripheral devices. For example, the processor 202 may communicate with a peripheral device 250-P in the plurality of peripheral devices 250-1 ... 250-P through the interconnect 110 based on the interconnect scheme 404 according to a common framework for interaction between the processor 202 and the plurality of peripheral devices 2501 ... 250-P. For example, software executing on the processor 202 may communicate with the peripheral device 250P using circuitry fabricated based on the interconnect scheme 404.

[0186] At block 804, the peripheral device communicates with the processor through the interconnect according to the common framework based on the interconnect scheme. For example, the peripheral device 250-P may communicate with the processor 202 through the interconnect 110 according to the common framework based on the interconnect scheme 404. In some cases, the peripheral device 250-P may respond to software executing on the processor 202, such as by providing a decryption result using the interconnect 110. Alternatively, if the interrupt is transmitted via the interconnect 110, the interrupt signal 506 may be transmitted to the interrupt handling circuitry of the processor 202.

[0187] At block 806, the peripheral device communicates with another peripheral device in the plurality of peripheral devices according to a common framework for interaction between at least two peripheral devices in the plurality of peripheral devices based on an inter-device scheme. For example, the peripheral device 250-P may communicate with another peripheral device 250-1 in the plurality of peripheral devices 250-1 ... 250-P based on the inter-device scheme 406 according to a common framework for interaction between at least two peripheral devices in the plurality of peripheral devices 250. To this end, the peripheral device 250-P may use a circuit system (e.g., one or more wires, buffers, or modules) and a communication protocol 320 established based on the inter-device scheme 406 of the interface specification 402 to transmit at least one signal to the peripheral device 250-1.

[0188] Fig. 9 An additional example method of an apparatus for implementing compatibility of a peripheral device with a secure circuit system is illustrated by flowchart 900. Flowchart 900 includes three blocks 902-906.

[0189] At block 902, an electronic device receives peripheral device design code corresponding to a peripheral device for a secure circuit system, wherein the peripheral device design code includes one or more indications of inter-device signaling. For example, in electronic device 1000 (described below), Fig.10 The compatibility analysis module 410 executed on the secure circuit system 106 may receive a peripheral device design code 412 corresponding to the peripheral device 250 of the secure circuit system 106, the peripheral device design code 412 including one or more indications of inter-device signaling 420. The one or more indications of inter-device signaling 420 may include, for example, names and other attributes of signals to be communicated between at least two peripheral devices, such as at least one inter-device communication 316.

[0190] At block 904, the electronic device analyzes the peripheral device design code, including comparing one or more indications of inter-device signaling with an inter-device scheme of an interface specification of a common framework for communicating at least within the secure circuit system. For example, a compatibility analysis module 410 executed on the electronic device 1000 may analyze the peripheral device design code 412, including comparing one or more indications of inter-device signaling 420 with an inter-device scheme 406 of an interface specification 402 of a common framework for communicating at least within the secure circuit system 106. In some cases, the compatibility analysis module 410 may ensure that the one or more indications of inter-device signaling 420 conform to the conventions set forth in the inter-device scheme 406 in terms of the existence, syntax, and relationships between two or more allowed attributes.

[0191] At block 906, in response to the analysis, the electronic device provides a compatibility report indicating whether the peripheral device design code is consistent with the inter-device scheme of the interface specification. For example, in response to the analysis, the compatibility analysis module 410 of the electronic device 1000 can provide a compatibility report 416 indicating whether the peripheral device design code 412 is consistent with the inter-device scheme 406 of the interface specification 402. Here, as part of generating the compatibility report 416, the compatibility analysis module 410 can identify at least one inter-device signaling indication 420 that does not comply with the inter-device scheme 406. The compatibility analysis module 410 can also include in the compatibility report 416 a reference to a relevant portion of the interface specification 402 or a prompt about fixing the violation so that the inter-device signaling indication 420 complies with the inter-device scheme 406.

[0192] Aspects of these methods may be implemented in, for example, hardware (e.g., fixed logic circuitry or a processor in conjunction with a memory), firmware, software, or some combination thereof. Figure 1 7 and 10 to implement these methods, which components can be further divided and combined, etc. The devices and components in these figures generally represent hardware, such as electronic devices, PCBs, packaged modules, IC chips, components or circuits; firmware; software; or a combination thereof. Therefore, these figures illustrate some of the many possible systems or devices that can implement the described methods.

[0193] For the methods described herein and the associated flow charts, the order in which the operations are displayed and / or described is not intended to be construed as limiting. Instead, any number or combination of the described method operations may be combined in any order to implement a given method or an alternative method. Operations may also be omitted from the described methods or added to them. In addition, the described operations may be implemented in a completely or partially overlapping manner.

[0194] Example Electronic Devices for Compatibility of Peripheral Devices with Safety Circuitry

[0195] Fig.10 Various components of an example electronic device 1000 are shown, which can implement compatibility of peripheral devices with a secure circuit system according to one or more described aspects. The electronic device 1000 can be implemented as any one or combination of a fixed device, a mobile device, a stand-alone device, or an embedded device; in the form of a consumer, computer, portable, user, server, communication, telephone, navigation, gaming, audio, camera, messaging, media playback, and / or other type of electronic device 1000 - such as in Figure 1 Any form of implementation of a smartphone is described as the apparatus 102. One or more of the illustrated components may be implemented as discrete components or integrated components on at least one integrated circuit of the electronic device 1000.

[0196] The electronic device 1000 may include one or more communication transceivers 1002 that enable wired and / or wireless communication of device data 1004, such as received data, transmitted data, or other information identified above. Example communication transceivers 1002 include near field communication (NFC) transceivers, various IEEE 802.15 (Bluetooth) compliant TM ) standard wireless personal area network (PAN) (WPAN) radio, compliant with various IEEE 802.11 (Wi-Fi TM ) standards, wireless local area network (LAN) (WLAN) radios for cellular phones (such as those compliant with 3GPP), various IEEE 802.16 (WiMAX) TM ) standard wireless metropolitan area network (MAN) (WMAN) radio, infrared (IR) transceiver compliant with the Infrared Data Association (IrDA) protocol, and wired local area network (LAN) (WLAN) Ethernet transceiver.

[0197] The electronic device 1000 may also include one or more data input ports 1006, through which any type of data, media content, and / or other input may be received, such as user-selectable input, messages, applications, music, television content, recorded video content, and any other type of audio, video, and / or image data received from any content and / or data source, including sensors such as microphones or cameras. The data input ports 1006 may include USB ports, coaxial cable ports, fiber optic ports for fiber optic interconnection or wiring, and other serial or parallel connectors (including internal connectors) for flash memory, DVDs, and CDs, etc. These data input ports 1006 may be used to couple the electronic device to components, peripherals, or accessories, such as keyboards, microphones, cameras, or other sensors.

[0198] The electronic device 1000 of this example includes at least one processor 1008 (e.g., any one or more of an application processor, a microprocessor, a digital signal processor (DSP), and a controller, etc.), which may include a combined processor and a memory system (e.g., implemented as part of a SoC), which processes (e.g., executes) computer executable instructions to control the operation of the device. The processor 1008 can be implemented as an application processor, an embedded controller, a microcontroller, a security processor, and an artificial intelligence (AI) accelerator, etc. In general, the processor or processing system can be at least partially implemented in hardware, which can include components of an integrated circuit or a system on a chip, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations using silicon and / or other materials.

[0199] Alternatively or additionally, the electronic device 1000 may be implemented with any one or combination of electronic circuit systems, which may include software, hardware, firmware, or fixed logic circuit systems implemented in conjunction with processing and control circuits, which are generally represented by 1010 (as electronic circuit system 1010). The electronic circuit system 1010 may be implemented, such as by processing / computer executable instructions stored on a computer readable medium and by logic circuit systems and / or hardware (e.g., such as FPGAs) to implement executable or hardware-based modules ( Fig.10 not shown).

[0200] Although not shown, the electronic device 1000 may include a system bus, interconnect, crossbar switch, data transmission system, or other switching structure coupling various components within the device. The system bus or interconnect may include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any one of a variety of bus architectures.

[0201] The electronic device 1000 also includes one or more memory devices 1012 that enable data to be stored, examples of which include random access memory (RAM), non-volatile memory (e.g., read-only memory (ROM), flash memory, EPROM, and EEPROM), and disk storage devices. Therefore, the memory devices 1012 can be distributed on different logical storage levels of the system and distributed at different physical components. The memory devices 1012 provide data storage mechanisms to store device data 1004, other types of code and / or data, and various device applications 1020 (e.g., software applications or programs). For example, an operating system 1014 can be saved as software instructions within the memory device 1012 and executed by the processor 1008.

[0202] In some implementations, the electronic device 1000 also includes an audio and / or video processing system 1016 that processes audio data and / or passes audio and video data to an audio system 1018 and / or a display system 1022 (e.g., a video buffer or a screen of a smartphone or camera). The audio system 1018 and / or the display system 1022 may include any device that processes, displays, and / or otherwise presents audio, video, display, and / or image data. The display data and audio signals may be transmitted to the audio component and / or display component via an RF (radio frequency) link, an S-video link, an HDMI (High Definition Multimedia Interface), a composite video link, a component video link, a DVI (digital video interface), an analog audio connection, a video bus, or other similar communication link, such as a media data port 1024. In some implementations, the audio system 1018 and / or the display system 1022 are external or separate components of the electronic device 1000. Alternatively, the display system 1022 may be, for example, an integrated component of the example electronic device 1000, such as part of an integrated touch interface.

[0203] Fig.10 The electronic device 1000 is Figure 1 Example implementation of the device 102 capable of implementing Figure 4 Example implementations of an apparatus for analyzing 414 and capable of implementing Figure 8 and 9 An example implementation of a device of any method. The electronic device 1000 may therefore include a security circuit system 106, which may be a separate IC chip or included as part of another IC chip or device - such as a processor 1008, an electronic circuit system 1010, or a memory device 1012. Therefore, for example, one or more of the components shown may be integrated on the same IC chip - such as a SoC - or at least integrated on a single PCB. As shown, the electronic device 1000 may additionally or alternatively include a compatibility analysis module 410. For example, the memory device 1012 may store the compatibility analysis module 410, and the processor 1008 may execute the compatibility analysis module 410. Therefore, the memory device 1012 may also store peripheral device design code 412 and interface specifications 402, etc. The electronic device 1000 may alternatively use the communication transceiver 1002 or the data input port 1006 to access the interface specification 402 or the peripheral device design code 412. Therefore, the principles of compatibility of peripheral devices with security circuit systems as described herein can be achieved by Fig.10 Electronic device 1000 or combined Fig.10 The electronic device 1000 is implemented.

[0204] Other Examples

[0205] In the following, some examples are described.

[0206] Example 1: An integrated circuit including a secure circuit system, the secure circuit system comprising: an interconnect; a processor coupled to the interconnect; and, a plurality of peripherals, each respective peripheral coupled to the interconnect and comprising an interface configured to comply with a common framework for interacting with the processor and other peripherals of the plurality of peripherals, the interface comprising: an interconnect interface configured to couple the respective peripheral to the interconnect; and, an inter-device interface configured to couple the respective peripheral to other peripherals of the plurality of peripherals.

[0207] Example 2: The integrated circuit of Example 1, wherein each respective peripheral device comprises a respective security function module configured to provide a respective security-related function.

[0208] Example 3: The integrated circuit of Example 1 or 2, wherein the corresponding security-related function includes at least one of the following: alarm handling; cryptographic operation; secure data storage; random number generation; or input / output communication of the secure circuit system.

[0209] Example 4: An integrated circuit according to any of the preceding examples, wherein the inter-device interface is coupled to at least one conductor extending to another peripheral device of the plurality of peripheral devices in response to a property included in the design code for the corresponding peripheral device.

[0210] Example 5: An integrated circuit according to any of the preceding examples, wherein the interface includes a clock interface, the clock interface including access to: a primary system clock, the corresponding peripheral device being configured to access the interconnect based at least on the primary system clock; and, one or more secondary system clocks, the corresponding peripheral device being configured to perform a function or communicate with another peripheral device among the plurality of peripheral devices based on the one or more secondary system clocks.

[0211] Example 6: An integrated circuit according to any of the preceding examples, wherein: the corresponding peripheral device includes a register interface, the register interface includes at least one interrupt entry for an interrupt associated with the corresponding peripheral device; and the corresponding peripheral device is configured to expose at least a portion of the register interface to the processor.

[0212] Example 7: An integrated circuit according to any of the preceding examples, wherein: the at least one interrupt entry includes: an interrupt enable indication; an interrupt status indication; and, an interrupt test register; and the corresponding peripheral device is configured to provide the processor with access to clear the interrupt status indication.

[0213] Example 8: An integrated circuit according to any of the preceding examples, wherein: the corresponding peripheral device among the plurality of peripheral devices includes at least one alarm transmitter module; and the alarm transmitter module is configured to transmit an alarm indication from the corresponding peripheral device via a signaling path.

[0214] Example 9: An integrated circuit according to any of the preceding examples, wherein: the signaling path includes at least one differential path; and the alarm transmitter module is configured to transmit an alarm integrity fault signal in response to detecting an integrity fault of the at least one differential path of the signaling path.

[0215] Example 10: An integrated circuit according to any of the preceding examples, wherein the integrated circuit comprises at least one of: a system on a chip (SoC); or a root of trust (RoT) chip.

[0216] Example 11: A method for compatibility of peripheral devices with a security circuit system, the method comprising: based on an interconnection scheme according to a common framework for interaction between the processor and the multiple peripheral devices, the processor communicating with a peripheral device among the multiple peripheral devices through an interconnection; based on the interconnection scheme according to the common framework, the peripheral device communicating with the processor through the interconnection; and, based on an inter-device scheme according to the common framework for interaction between at least two of the multiple peripheral devices, the peripheral device communicating with another peripheral device among the multiple peripheral devices.

[0217] Example 12: The method of Example 11, wherein the peripheral device communicating with the other peripheral device of the plurality of peripheral devices comprises: the peripheral device communicating with the other peripheral device bypassing the interconnect.

[0218] Example 13: A method according to Example 11 or 12, wherein the peripheral device communicating with the other peripheral device among the multiple peripheral devices includes: the peripheral device transmitting an inter-device signal to the other peripheral device using a circuit derived from a property specified by a design code for the peripheral device.

[0219] Example 14: A method according to any one of Examples 11 to 13, wherein: the communication between the peripheral device and the processor through the interconnect includes the peripheral device transmitting an interrupt signal to the processor based on an interrupt status indication of an interrupt entry of the peripheral device; and the communication between the processor and the peripheral device through the interconnect includes clearing the interrupt status indication of the interrupt entry.

[0220] Example 15: A method according to any one of Examples 11 to 14, wherein: the communication between the peripheral device and the other peripheral device among the multiple peripheral devices includes receiving an upgrade command by the peripheral device from the other peripheral device, and the other peripheral device includes an alarm handler; and the method also includes activating a countermeasure by the peripheral device in response to receiving the upgrade command from the alarm handler.

[0221] Example 16: A method for compatibility of a peripheral device with a secure circuit system, the method comprising: receiving a peripheral device design code corresponding to a peripheral device for a secure circuit system, the peripheral device design code including one or more indications of inter-device signaling; analyzing the peripheral device design code, including comparing the one or more indications of inter-device signaling with an inter-device scheme of an interface specification of a common framework for communicating at least within the secure circuit system; and in response to the analysis, providing a compatibility report indicating whether the peripheral device design code is consistent with the inter-device scheme of the interface specification.

[0222] Example 17: A method according to Example 16, wherein: one or more indications of inter-device signaling relate to signals exchanged between two or more peripheral devices without using an interconnect of a secure circuit system; and an inter-device scheme establishes a format for defining inter-device signaling that bypasses the interconnect.

[0223] Example 18: The method of example 16 or 17, wherein the inter-device scheme comprises a mandatory part and an optional part.

[0224] Example 19: A method according to any one of Examples 16 to 18, wherein the peripheral device design code includes one or more indications of processor-device signaling, and the method further includes: analyzing the peripheral device design code, including comparing the one or more indications of processor device signals with an interconnection scheme of an interface specification of a common framework; in response to the analysis including comparing the one or more indications of processor-device signaling, generating a compatibility report to indicate whether the peripheral device design code is consistent with the interconnection scheme of the interface specification.

[0225] Example 20: A method according to any one of Examples 16 to 19, wherein the peripheral device design code includes one or more indications of interrupt signaling, and the method further includes: analyzing the peripheral device design code, including comparing the one or more indications of interrupt signaling with the interrupt scheme of the interface specification for the common framework; and in response to the analysis including comparing the one or more indications of interrupt signaling, generating a compatibility report to indicate whether the peripheral device design code is consistent with the interrupt scheme of the interface specification.

[0226] Unless the context indicates otherwise, the use of the word "or" herein may be considered as use of an "inclusive or" or a term allowing inclusion or application of one or more items linked by the word "or" (e.g., the phrase "A or B" may be interpreted as allowing only "A", only "B", or both "A" and "B"). In addition, as used herein, a phrase referring to "at least one" of a list of items refers to any combination of those items, including single members. For example, "at least one of a, b, or c" may encompass a, b, c, ab, ac, bc, and abc, as well as any combination with multiple identical elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc or any other order of a, b, and c). In addition, items represented in the drawings and terms discussed herein may indicate one or more items or terms, and thus may refer interchangeably to items and terms in the singular or plural form in this written description. Although implementations for compatibility of peripheral devices with secure circuit systems have been described in language specific to certain features and / or methods, the subject matter of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as example implementations for compatibility of peripheral devices with secure circuit systems.

Claims

1. A device comprising: An integrated circuit chip including a safety circuit system, the safety circuit system comprising: interconnection; a processor coupled to the interconnect; at least one bus; and a plurality of peripheral devices, each peripheral device coupled to the interconnect and the at least one bus, each peripheral device comprising an interface, the interface configured to adhere to a common framework for interacting with the processor and one or more other peripheral devices of the plurality of peripheral devices, the interface comprising: an interconnect interface configured to couple a corresponding peripheral device to the interconnect, the corresponding peripheral device being configured to communicate with the processor via the interconnect using the interconnect interface; and an inter-device interface configured to couple the corresponding peripheral device to the one or more other peripheral devices of the plurality of peripheral devices, the corresponding peripheral device being configured to communicate with the one or more other peripheral devices of the plurality of peripheral devices via the at least one bus using the inter-device interface, wherein the inter-device interface is coupled to at least one wire extending to another peripheral device of the plurality of peripheral devices in response to a property included in the design code for the corresponding peripheral device.

2. The device according to claim 1, wherein: Each peripheral device includes a corresponding safety function module configured to provide a corresponding safety-related function.

3. The device according to claim 2, wherein: The corresponding safety-related functions include at least one of the following: Alarm handling; Cryptographic operations; Secure data storage; Random number generation; and Input / output communications of the safety circuit system.

4. The device according to claim 1, wherein: The interface includes a clock interface, the clock interface including access to: a primary system clock, the respective peripherals being configured to communicate with the processor using the interconnect based at least on the primary system clock; as well as One or more secondary system clocks, the corresponding peripheral device being configured to use the at least one bus to perform a function or communicate with another peripheral device of the plurality of peripheral devices based at least on the one or more secondary system clocks.

5. The device according to claim 1, wherein: The corresponding one of the plurality of peripheral devices comprises at least one alarm transmitter module; and The at least one alarm transmitter module is configured to transmit an alarm indication from the corresponding peripheral device via a signaling path.

6. The device according to claim 5, wherein: The signaling path includes at least one differential path; and The at least one alarm transmitter module is configured to transmit an alarm integrity fault signal in response to detecting an integrity fault of the at least one differential path of the signaling path.

7. The device according to claim 1, wherein: The integrated circuit chip includes at least one of the following: System on a Chip (SoC); and Root of Trust (RoT) chip.

8. The device according to any one of claims 1 to 7, wherein: The corresponding peripheral device includes a register interface including at least one interrupt entry for an interrupt associated with the corresponding peripheral device; and The corresponding peripheral device is configured to expose at least a portion of the register interface to the processor.

9. The device according to claim 8, wherein: The at least one interrupt entry comprises: Interrupt enable indication; Interrupt status indication; and Interrupt test registers; and The corresponding peripheral device is configured to provide the processor with access to clear the interrupt status indication.

10. The device according to claim 1, wherein: The at least one bus is dedicated to the plurality of peripheral devices.

11. A method for compatibility of a peripheral device with a security circuit system, the security circuit system being part of an integrated circuit chip, the method comprising: Based on the interconnection scheme according to a common framework for interaction between the processor and the plurality of peripheral devices, the processor communicates with the peripheral devices in the plurality of peripheral devices through the interconnection; the security circuit system includes the processor, the plurality of peripheral devices, the interconnection and at least one bus; the peripheral device includes an interface, the interface includes an interconnection interface and an inter-device interface; Based on the interconnection scheme and in accordance with the common framework, the peripheral device communicates with the processor through the interconnection and via the interconnection interface; as well as According to the common framework for interaction between at least two peripheral devices among the plurality of peripheral devices based on an inter-device scheme, the peripheral device communicates with another peripheral device among the plurality of peripheral devices through the at least one bus and via the inter-device interface, wherein the peripheral device communicates with the another peripheral device among the plurality of peripheral devices through the at least one bus and via the inter-device interface comprises: Inter-device signals are transmitted by the peripheral device to the other peripheral device using circuitry derived from properties specified by the design code for the peripheral device.

12. The method according to claim 11, wherein: Communicating, by the peripheral device, with the other peripheral device of the plurality of peripheral devices through the at least one bus and via the inter-device interface comprises: The peripheral device communicates with the other peripheral device by bypassing the interconnect.

13. The method according to claim 11, wherein: Communicating, by the peripheral device, with the other peripheral device of the plurality of peripheral devices over the at least one bus and via the inter-device interface comprises receiving, by the peripheral device, an upgrade command from the other peripheral device, the other peripheral device comprising an alarm handler; and The method further includes activating, by the peripheral device, a countermeasure in response to receiving the escalation command from the alarm handler.

14. A method according to any one of claims 11 to 13, wherein: Communicating with the processor by the peripheral device through the interconnect and via the interconnect interface includes transmitting, by the peripheral device, an interrupt signal to the processor based on an interrupt status indication of an interrupt entry of the peripheral device; as well as Communicating, by the processor, with the peripheral device via the interconnect includes clearing the interrupt status indication of the interrupt entry.

Images