Flexible queue provisioning for partitioned acceleration devices

Abstract

Embodiments herein describe wrapping non-safety compliant hardware resources with error detection checks to meet safety standards, thereby allowing the non-safety compliant hardware to be used to perform one or more tasks within a system that as a whole meets a particular safety standard (e.g., one of ASIL QM, A, B, C, and D grades).

Description

[Technical field]

[0001] Examples of this disclosure generally relate to wrapping non-safety compliant hardware resources with error detection checks to meet safety standards. [Background technology]

[0002] Safety-critical industries such as the automotive industry often desire safe communication between control units and peripherals, for example to enable automatic emergency braking (AEB) systems. Automotive Safety Integrity Level (ASIL) is a risk classification system defined by the ISO26262 standard. The safety requirements defined in this standard, from lowest to highest, are ASIL QM, A, B, C, and D. Designing an integrated circuit (IC) with sufficient safety mechanisms to comply with the ASIL-D grade requires significant development costs.

[0003] Current approaches rely on using ASIL-compliant building blocks to achieve safety protection at the system / channel level, which adds cost and complexity: each component in the system is designed to comply with a desired ASIL grade (e.g., ASIL D). This prevents other hardware resources from being used to perform one or more tasks in the system if those resources are not ASIL-compliant. Summary of the Invention

[0004] One example is an integrated circuit including a first circuit configuration that complies with a safety standard and is configured to generate an error detecting code for a message to be transmitted by the IC to an external destination, a second circuit configuration that does not comply with the safety standard and performs a task using the message and the error detecting code, and a transceiver configured to transmit the message and the error detecting code to the external destination, where the first circuit configuration, the second circuit configuration, and the transceiver are part of a communication channel that meets the safety standard.

[0005] One example described herein is a system, the system includes a first IC, the first IC includes a first processor that complies with a safety standard, the first processor configured to receive a message transmitted by the IC to an external destination and generate an error detection code for the message. The first IC also includes a first cryptographic engine configured to encrypt the message and the error detection code, and a first transceiver configured to transmit the encrypted message and the error detection code. The system also includes a second IC, the second IC includes a second transceiver configured to receive the encrypted message and the error detection code from the first IC, a second cryptographic engine configured to decrypt the encrypted message and the error detection code, and a second processor that complies with a safety standard, the second processor configured to check whether the decoded message has an error by using the decoded error detection code. Furthermore, at least one of the first cryptographic engine or the second cryptographic engine does not comply with a safety standard.

[0006] One example described herein is a method that includes receiving a message to be transmitted from an IC to an external destination, generating an error detecting code for the message using first circuitry in the IC, the first circuitry complying with a safety standard, performing a task using the message and the error detecting code using second circuitry in the IC, the second circuitry not complying with the safety standard, and after performing the task, transmitting the message and the error detecting code to the external destination, where the first circuitry and the second circuitry are part of a communication channel that meets the safety standard.

[0007] In a manner in which the above-recited features may be understood in detail, a more particular description briefly summarized above may be made by reference to exemplary implementations, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical example implementations and therefore should not be considered as limiting the scope thereof. [Brief description of the drawings]

[0008] [Figure 1] According to one example, an IC has ASIL compliant and non-ASIL compliant hardware. [Diagram 2] 2 is a communication system for automotive applications using the IC from FIG. 1, according to an example. [Diagram 3] 1 is a flow chart for wrapping non-safety compliant hardware resources with error detection checks to meet safety standards, according to an example. [Figure 4] 1 is a communication system of a non-ASIL compliant crypto engine wrapped with an ASIL compliant error code check, according to one embodiment. [Diagram 5] 1 illustrates an IC having an ASIL domain and a non-ASIL domain, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] For ease of understanding, wherever possible, identical reference numbers have been used to designate identical elements common to the figures. It is contemplated that elements of one embodiment may be beneficially incorporated in other embodiments.

[0010] Various features are described below with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description of features or as limitations on the scope of the claims. In addition, the illustrated examples do not necessarily have all aspects or advantages shown. An aspect or advantage described in connection with a particular embodiment is not necessarily limited to that embodiment and can be implemented in any other embodiment, even if not so illustrated or explicitly described.

[0011] Embodiments herein describe wrapping non-safety compliant hardware resources with error detection checks to meet safety standards. Doing so allows the non-safety compliant hardware to be used to perform one or more tasks in a system that as a whole meets a particular safety standard (e.g., one of ASIL A, B, C, and D grades). For example, a safety-critical industry may want communications between components and peripherals to be safe (e.g., meet a particular ASIL grade) and secure (perform data encryption). In one embodiment, an integrated circuit (IC) may include a cryptographic engine that is not ASIL certified. That is, the cryptographic engine may not have been certified or certified to ensure that it has sufficient diagnostic coverage for failure mechanisms such as bit flips or transistor destruction.

[0012] Rather than designing a new crypto engine that is ASIL certified, embodiments herein wrap non-ASIL compliant hardware (e.g., a crypto engine) with ASIL compliant error checking capabilities. For example, before sending a message to a component or peripheral, an IC may first add an error detection code (e.g., a cyclic redundancy check (CRC) code) to the message. The message and the error detection code may then be encrypted by a non-ASIL compliant crypto engine to form an encrypted payload. This payload may then be received by another IC, which uses its crypto engine (which may be ASIL compliant or non-ASIL compliant) to decrypt the payload and evaluates the error detection code using its error detection capabilities to ensure that no errors were introduced by the non-ASIL compliant hardware (i.e., one or both of the crypto engines). In this manner, non-ASIL compliant hardware may be used in an ASIL compliant communication system.

[0013] 1 is an IC 100 having ASIL-compliant and non-ASIL-compliant hardware, according to an example. The IC 100 can be formed from one or more semiconductor materials. The IC 100 can be an application specific IC (ASIC), a field programmable gate array (FPGA), or a system on a chip (SoC). In one embodiment, the IC 100 includes only hardened, non-programmable circuitry. However, in another embodiment, the IC 100 includes both hardened circuitry and programmable logic.

[0014] The IC includes ASIL-compliant circuitry 105 and non-ASIL-compliant circuitry 125. That is, the ASIL-compliant circuitry 105 is designed and proven through testing or certified to ensure that it meets a particular ASIL grade (e.g., ASIL-D), while the non-ASIL-compliant circuitry 125 is not. Although embodiments herein are described in the context of ASIL, they may be applied to any safety-related certification process or standard. For example, embodiments may be used with Safety Integrity Level (SIL) standards in non-automotive type safety applications, such as for industrial equipment.

[0015] ASIL-compliant circuitry 105 includes processor 110 and memory 120. Processor 110 may represent one or more hardened processors, each having one or more processing cores. These cores may be designed, proven through testing, or certified to ensure that they have sufficiently high diagnostic coverage of single-point or latent faults (e.g., random errors from bit flips, or destructive errors due to faulty circuitry).

[0016] Memory 120 can include volatile and non-volatile memory. Like processor 110 (and its cores), memory 120 can be designed, proven through testing, or certified to ensure that it has a sufficiently high diagnostic coverage of single point failures or potential failures. In this example, memory 120 is disposed on IC 100, but can also include memory that can be external to IC 100.

[0017] The non-ASIL compliant circuitry 125 includes a crypto engine 130 that includes circuitry that is not ASIL compliant. That is, the IC 100 may not guarantee that the circuitry in the crypto engine 130 meets a particular ASIL grade. For example, the IC 100 may be designed to be used in an automotive system that requires a particular ASIL grade. The IC designer saves both time and cost by implementing the crypto engine 130 as a non-ASIL compliant circuitry 125. However, a customer may want to add security to a communication channel by performing data encryption. The IC 100 includes a crypto engine 130, but is not ASIL compliant. Instead of having to design a new IC with an ASIL compliant crypto engine 130, embodiments herein allow the non-ASIL compliant crypto engine 130 to be used in automotive tasks that require ASIL compliance.

[0018] The processor 110 provides error detection circuitry 115 that adds an error detection code (e.g., a CRC code) to messages being communicated in an ASIL-compliant communication channel. Although embodiments herein illustrate dedicated circuitry 115 that adds the error detection code, in other embodiments, the error detection function is provided using software running on the processor 110. As a result, the crypto engine 130 can be used to encrypt transmitted messages (and decrypt received packages) even if it is not ASIL-compliant. The error detection code can be used to catch any errors introduced from using the crypto engine 130, thereby ensuring that the communication channel as a whole meets the ASIL grade. In other words, the non-ASIL-compliant crypto engine 130 is wrapped around by the ASIL-compliant circuitry 105, so that the communication channel as a whole is ASIL-compliant even if some parts of the channel (e.g., the encryption / decryption engine) are not ASIL-compliant. This is discussed in more detail in the following figures.

[0019] Although FIG. 1 illustrates wrapping the crypto engine 130 with ASIL-compliant circuitry 105, embodiments herein are not limited to using a non-ASIL-compliant crypto engine 130. Other types of non-ASIL-compliant hardware can be wrapped by ASIL-compliant circuitry 105 to make the communication channel ASIL-compliant. For example, DMA reads / writes can also be performed by non-ASIL-compliant hardware as described in FIG. 5 below. Thus, when designing a new IC, a system designer can identify components that can be wrapped by ASIL-compliant hardware and thus decide not to perform the time-intensive process of designing and testing these components to be ASIL-compliant. This can reduce the overall cost of the IC without compromising safety.

[0020] Although FIG. 1 illustrates that the crypto engine 130 is non-ASIL compliant, in other embodiments, the crypto engine 130 may be ASIL compliant but of a lower grade. For example, the crypto engine 130 may be ASIL-B and the processor 110 and memory 120 are ASIL-D. If a customer decides to use the IC 100 in an application that requires ASIL-D, the crypto engine 130 will not qualify. However, using embodiments herein, a lower grade ASIL component can be used in a higher grade ASIL task. That is, an ASIL-B crypto engine is wrapped by ASIL-D hardware for the task to meet ASIL-D requirements. Thus, using embodiments herein, a non-ASIL compliant hardware (or lower ASIL compliant hardware) can be wrapped with ASIL compliant hardware having the desired ASIL grade for a particular automotive task.

[0021] FIG. 2 is a communication system 200 for an automotive application using the IC from FIG. 1, according to an example. In this example, the communication system 200 includes a first IC 100A and a second IC 100B, each having an electronic control unit (ECU) 205, a controller area network (CAN) controller 210, and a CAN transceiver 215, which may include a protocol level controller. The ECU 205 may control different systems in an automobile, such as the engine, suspension, airbags, brakes, and accelerator. In many cases, the control of these systems requires the ECUs 205 to communicate with each other and with other systems in the automobile, as illustrated by FIG. 2. For example, the IC 100 may use a bus (not shown) to communicatively couple the various systems.

[0022] The CAN controller 210 can use a multi-master CAN protocol for real-time control of the ECU 205. In one embodiment, the CAN controller 210 can communicate using the CAN Flexible Data Rate (FD) of the CAN protocol. Although FIG. 2 illustrates using the CAN protocol, embodiments herein are not so limited. Other communication protocols, such as Ethernet, can be used to communicate between the ICs 100.

[0023] CAN transceiver 215 includes digital and analog components (e.g., analog front end) for transmitting messages (e.g., data packets) between ICs 100. These messages may include commands, measurements, requests for information, etc. ECU 205, CAN controller 210, and CAN transceiver 215 may be ASIL compliant so that end-to-end protection from hardware errors may be achieved. However, as discussed above, some of the components in CAN controller 210 and CAN transceiver 215 may not be ASIL compliant. For example, CAN controller 210 or CAN transceiver 215 may include a non-ASIL compliant encryption and decryption engine (e.g., crypto engine 130 of FIG. 1) that performs data encryption on messages being exchanged by ICs 100. Thus, FIG. 2 illustrates that ICs 100 may include non-ASIL compliant components and still achieve ASIL compliant communication channels between ICs 100 (and between ECUs 205).

[0024] 3 is a flow chart of a method 300 for wrapping a non-safety compliant hardware resource with an error detection check to meet a safety standard, according to an example. At block 305, error detection circuitry (e.g., error detection circuitry 115 of FIG. 1) or software running on a processor receives a message intended to be sent over a communication channel that complies with a safety standard, such as an ASIL, a SIL, or some other safety standard or certification. For example, the communication channel may meet a particular ASIL grade, such as ASIL-D.

[0025] In one embodiment, the error detection function is implemented on a portion of the safety compliant IC, i.e., the error detection circuitry may be dedicated ASIL compliant hardware. In one example, the error detection function may be implemented as a software function on a general purpose processor.

[0026] Generally, method 300 can be used for any communication channel where the channel meets a particular safety standard. In most safety-critical applications, the individual components in the communication channel meet the same safety standard. However, in method 300, there is at least one component that is not present in the communication channel. Error detection circuitry or software can be used to isolate or wrap around the non-safety compliant hardware so that any errors generated by the non-safety compliant hardware are detected in order to meet the safety standard.

[0027] At block 310, error detection circuitry or software generates an error detection code for the message. In one embodiment, the error detection code is generated based on the data (e.g., 1s and 0s) in the message. One common error detection code is a CRC that uses information in the message, such as the remainder of a polynomial division of the contents, to generate a CRC code value (e.g., a check value). However, embodiments herein are not limited to any particular type of error detection technique.

[0028] In one embodiment, the number of bits used in the error detection code may vary depending on the desired level of the safety standard. A larger number of bits may enable the error detection technique to better detect errors in the message. For example, the error detection circuitry or software may use fewer bits in the error detection code when ensuring that the communication channel complies with ASIL-C than when ensuring that the communication channel complies with ASIL-D, which has a smaller tolerance for errors. Thus, the size and precision of the error detection code may vary depending on the particular level or grade of the safety standard. While it is desirable to use the error detection code to detect all errors, this can be balanced against the additional overhead introduced by adding the error detection code to the message.

[0029] In block 315, a crypto engine (e.g., crypto engine 130 of FIG. 1) encrypts the message and an error detection code. In this example, the crypto engine is a non-safety compliant crypto engine. For example, the crypto engine has not been certified to meet a particular level or grade of ASIL or SIL required for the communication channel. Nevertheless, as described below, the error detection code can be used to ensure that the crypto engine did not introduce errors into the message. Thus, the communication channel provides end-to-end protection that meets the desired level or grade of safety standard.

[0030] The cryptographic engine may use any suitable cryptographic technique to generate the encrypted payload by encrypting the message and the error detecting code. The message and the error detecting code may be encrypted together or separately to form the encrypted payload.

[0031] In block 320, the IC transmits the encrypted payload to another IC. The IC that transmits the encrypted payload (i.e., the transmitting IC) can be the same IC that has the crypto engine and error detection circuitry that performed blocks 305-315. Thus, the transmitting IC can have circuitry that complies with the security protocol and circuitry that does not comply with the security protocol.

[0032] In one embodiment, the transmitting IC uses a suitable communication protocol, such as the CAN protocol or Ethernet, to transmit the encrypted payload to the receiving IC. In one embodiment, the payload is transmitted to the receiving IC in one or more packets.

[0033] In block 325, the crypto engine on the receiving IC decrypts the encrypted payload. Like the crypto engine on the transmitting IC, the crypto engine on the receiving IC may be non-compliant with safety standards. That is, the crypto engine may not be certified for a particular grade or level of safety standard. Nevertheless, the error detection code added to the message in block 310 can be used to catch errors that may have occurred in any of the crypto engines in the IC.

[0034] However, in one embodiment, one of the crypto engines may be compliant with the safety protocol. That is, the crypto engine that encrypted the message and error detection code in block 315 may instead be compliant with the safety protocol, while the crypto engine that decrypts the encrypted payload in block 325 may not, or vice versa. As long as one component in the communication channel does not comply with the safety protocol, the method 300 can be used. This gives the system designer more flexibility. For example, some ICs may only have circuitry that complies with the safety protocol, while other ICs may not. Compliant ICs can still be used along with ICs that have one or more components that do not comply. Thus, the method 300 can give the system designer the ability to mix and match between ICs that may have components that do not comply with the desired level of the safety protocol.

[0035] In one embodiment, after decrypting the encrypted payload, the crypto engine on the receiving IC can reconstruct the message and error detection code. Assuming there are no errors, the message and error detection code produced in block 325 by decrypting the payload should be the same as the message and error detection code encrypted in block 315.

[0036] In block 330, error detection circuitry or software in the receiving IC performs an error check using the error detection code, i.e., the error detection circuitry or software can use the error detection code to determine whether errors were introduced into either the message or the error detection code when this data was encrypted and decrypted by hardware that does not comply with the secure protocol.

[0037] If the error detection circuitry or software detects that there is no error at block 335 (e.g., if the error detection code indicates that the message has correct data), the method 300 proceeds to block 340, where the message may be processed by downstream circuitry (e.g., an ECU or controller in the receiving IC).

[0038] However, if the error detection circuitry or software detects an error, method 300 proceeds to block 345 where the receiving IC performs troubleshooting. This may include requesting that the transmitting IC resend the message, sending an error to the operating system or primary controller, or changing the operating state of the system. For example, a cosmic ray may have flipped a bit in either the message or the error detection code, causing the error detection circuitry or software to detect an error in block 335. The receiving IC may request that the transmitting IC resend the message, which is unlikely to have the same error (because bit flips are rare events). However, if the receiving IC continues to detect errors, there may be a problem with the underlying circuitry in the cryptographic engine (e.g., a defective transistor). In that case, the receiving IC may alert the primary controller or operating system that there is a problem with the communication channel. The system may also enter a secure state to prevent any unsecure operating conditions.

[0039] 4 is a communication system of a non-ASIL compliant crypto engine wrapped with an ASIL compliant error code check, according to one embodiment. System 400 includes blocks 405-430 in a flow that is illustrated as either ASIL compliant or non-ASIL compliant. Additionally, blocks 405-430 are shown as being performed in one of two ICs. In this case, IC 100A is the transmitting IC and IC 100B is the receiving IC. However, the communication channel in FIG. 4 can be bidirectional, with IC 100B sending a message to IC 100A, in which case IC 100B is the transmitting IC and IC 100A is the receiving IC.

[0040] At block 405, IC 100A appends an error detection code to the message being sent to IC 100B. In one embodiment, the message is generated by circuitry on IC 100A. However, in another embodiment, the message is received by IC 100A from another component in the system (e.g., a sensor) and then forwarded by IC 100A to IC 100B.

[0041] In this embodiment, the circuitry within IC100A that generates and appends the error detection code to the message is ASIL compliant, i.e., the circuitry that performs this task (e.g., the error detection circuitry or software) is certified to meet the diagnostic coverage requirements of the desired ASIL grade.

[0042] In block 410, IC 100A encrypts the payload. This block may be performed by a crypto engine using any suitable encryption technique. However, unlike block 410, the circuitry that encrypts the payload is not ASIL compliant. In other words, the circuitry may not be certified to have diagnostic coverage of errors that meet the desired ASIL grade for the communication channel.

[0043] At block 410, IC 100A transmits the encrypted payload to IC 100B. The encrypted payload may include both a message and an error detection code, but remains encrypted. IC 100A may use any suitable communication protocol, such as CAN or Ethernet, to transmit the encrypted payload to IC 100B.

[0044] At block 420, IC100B decodes the payload. In this embodiment, block 420 is performed using circuitry in IC100B that is not ASIL compliant. That is, similar to block 410, the circuitry may not have been designed or certified to have the diagnostic coverage of errors required by the desired ASIL grade. However, as discussed above, the non-ASIL compliant circuitry in IC100A and IC100B can be wrapped or protected by ASIL compliant circuitry that generates error detection codes.

[0045] Although system 400 illustrates both IC100A and IC100B including non-ASIL compliant circuitry for performing encryption and decryption, in other embodiments, one of blocks 410 or 420 is performed by circuitry that is ASIL compliant, in which case the error detection code can still be used to detect errors that occur in the non-ASIL compliant circuitry.

[0046] At block 425, IC 100B performs an error check to determine whether an error was introduced by non-ASIL compliant circuitry in either IC 100A or IC 100B. In this manner, the non-ASIL compliant circuitry can be used to perform one or more tasks in the ASIL compliant communication channel. That is, system 400 can provide end-to-end protection that meets the requirements of a particular ASIL grade while still using non-ASIL compliant circuitry in one or both of ICs 100.

[0047] In block 430, downstream circuitry in IC100B receives an acknowledgment from the circuitry that executed block 425 indicating whether the message had an error. If not, the downstream circuitry is free to process the message. If not, IC100B can perform a troubleshooting action, such as one of the actions discussed in method 300.

[0048] 5 illustrates an IC 500 having an ASIL domain and a non-ASIL domain. The ASIL domain 505 of the IC 500 includes on-chip memory (OCM) 510, tightly coupled memory (TCM) 515, processor 520, and CAN transceiver 530. These components are designed and certified to achieve the desired ASIL grade because they are within the ASIL domain 505. In contrast, the non-ASIL domain 550 includes a controller 555, which includes a direct memory access (DMA) engine 560 and a crypto engine 565. These components are not certified to achieve the desired ASIL grade. Although the controller 555 is shown as a processing element within the IC 500 separate from the processor 520, in other embodiments the controller 555 may be part of the processor 520. For example, the processor 520 may have a first portion (eg, the core 525) that is ASIL compliant, but may have a second portion (eg, the controller 555) that is not ASIL compliant.

[0049] Using embodiments herein, hardware components in non-ASIL domain 550 can still be used to perform tasks within a safety-critical communication channel by wrapping these hardware components with hardware components in ASIL domain 505. For example, DMA engine 560 and crypto engine 565 can be used to enable secure communication between different ICs. This communication may be a safety-critical function where the communication channel must meet a desired ASIL grade.

[0050] In one embodiment, a core 525 in the processor 520 retrieves a message from the OCM 510 or the TCM 515, as indicated by arrow 570. For example, the message may have been generated by an ECU or using data from a sensor coupled to the IC 500. In either case, the IC 500 is tasked with sending the message to an external destination (e.g., another IC or component in a safety-critical system).

[0051] Core 525 may then generate an error detection code (e.g., a CRC check value) for the message. Core 525 may perform a process similar to that described in block 310 of Figure 3. Core 525 may then store the error detection code along with the message in OCM 510 or TCM 515. This is indicated by arrow 575.

[0052] Core 525 then instructs DMA engine 560 to retrieve the message and error detection code from OCM 510 or TCM 515. As indicated by arrow 580, DMA engine 560 performs a DMA read to retrieve the message and error detection code from OCM 510 or TCM 515.

[0053] The message and the error detecting code are then forwarded to cryptographic engine 565, as indicated by arrow 585. Cryptographic engine 565 then encrypts this data using a suitable encryption technique as discussed in block 315 of FIG.

[0054] After encrypting the data, DMA engine 560 can perform a DMA write to send the encrypted message and error detection code (e.g., encrypted payload) to core 525. This is indicated by arrow 590. Thus, the tasks performed by the non-ASIL compliant hardware, e.g., DMA reads and writes and data encryption, are performed at the behest of the ASIL compliant hardware, e.g., core 525. Thus, the ASIL compliant hardware can be considered to wrap around the non-ASIL compliant hardware that can use the error detection code to detect any errors that may have been introduced into the message. That is, when the encrypted payload is sent to another IC and decrypted, the ASIL compliant hardware in that IC can use the error detection code to ensure that the error coverage of the entire communication channel, including the non-ASIL compliant hardware in IC 500, meets the target ASIL standard.

[0055] Core 525 can then instruct CAN transceiver 530 to transmit the encrypted message and error detection code to another IC. This IC can use a non-ASIL compliant or ASIL compliant DMA engine and crypto engine to decrypt the data. The ASIL compliant core can then perform error checking before performing the task indicated by the message or before forwarding the message to downstream circuitry within the IC. In this way, multiple tasks such as DMA read / write and encryption / decryption can be performed by non-ASIL hardware in an ASIL compliant communication channel.

[0056] In the foregoing, reference is made to the embodiments presented in this disclosure. However, the scope of the disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated for implementing and practicing the contemplated embodiments. Furthermore, the embodiments disclosed herein may achieve other possible solutions or advantages over the prior art, but whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the disclosure. Thus, the above aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly recited in the claims.

[0057] As will be appreciated by one of ordinary skill in the art, embodiments disclosed herein may be embodied as a system, method, or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be generally referred to herein as a "circuit," "module," or "system." Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0058] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer readable storage media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a computer readable storage medium is any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0059] A computer-readable signal medium may include a propagated data signal in which computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium is not a computer-readable storage medium but may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0060] The program code embodied on the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0061] Computer program code for carrying out operations of aspects of the present disclosure may be written in any combination of one or more programming languages, including, for example, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may execute completely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).

[0062] Aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, cause a machine to create means for performing the functions / acts specified in the blocks of the flowchart and / or block diagrams.

[0063] These computer program instructions may also be stored on a computer-readable storage medium, where the instructions stored on the computer-readable storage medium can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner to produce an article of manufacture including instructions implementing aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0064] Computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide a process for performing the functions / acts specified in the flowchart and / or block diagram blocks.

[0065] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block of the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, as well as combinations of blocks in the block diagrams and / or flowchart illustrations, may be executed by a dedicated hardware-based system that performs the specified functions or acts, or a combination of dedicated hardware and computer instructions.

[0066] While the above is directed to particular examples, other and further examples may be devised without departing from the basic scope thereof, which is determined by the following claims.

Claims

1. 1. An integrated circuit (IC), comprising: a first circuit arrangement that complies with a safety standard and that is configured to generate an error detection code for a message transmitted by the IC to an external destination; a second circuit arrangement that does not comply with the safety standard, the second circuit arrangement using the message and the error detection code to perform a task; and a transceiver configured to transmit the message and the error detection code to the external destination, wherein the first circuitry, the second circuitry, and the transceiver are part of a communications channel that meets the safety standard.

2. 2. The IC of claim 1, wherein the second circuitry includes a cryptographic engine, and wherein the task includes the cryptographic engine encrypting the message and the error-detecting code.

3. The IC of claim 2 , wherein the transceiver is configured to transmit the encrypted message and an error detection code to the external destination.

4. 3. The IC of claim 2, wherein the error-detecting code is configured to detect errors introduced into the message or the error-detecting code due to non-compliance of the cryptographic engine with the security standard.

5. The IC of claim 4 , wherein the error detection code is a cyclic redundancy check (CRC) check value.

6. The IC of claim 1 , wherein the safety standard is a Safety Integrity Level (SIL).

7. 2. The IC of claim 1, wherein the safety standard is Automotive Safety Integrity Level (ASIL).

8. 1. A system comprising: A first IC, A first processor that complies with a safety standard, the first processor comprising: receiving a message to be transmitted by said IC to an external destination; a first processor configured to generate an error detection code for the message; a first encryption engine configured to encrypt the message and the error detecting code; a first IC including a first transceiver configured to transmit the encrypted message and the error detection code; a second IC, a second transceiver configured to receive the encrypted message and the error detection code from the first IC; a second cryptographic engine configured to decrypt the encrypted message and the error detection code; a second IC including a second processor that complies with the safety standard, the second processor being configured to check whether the decoded message has an error by using the decoded error detection code; At least one of the first cryptographic engine or the second cryptographic engine does not comply with the safety standard.

9. The system of claim 8 , wherein both the first cryptographic engine and the second cryptographic engine do not comply with the safety standard.

10. 9. The system of claim 8, wherein the error detection code is configured to detect errors introduced into the message or the error detection code due to non-compliance of the first or second cryptographic engines with the safety standard.

11. The system of claim 8 , wherein the safety standard is SIL.

12. The system of claim 11 , wherein the safety standard is ASIL.

13. The system of claim 12 , wherein the first IC includes an electronic control unit (ECU) configured to control an automotive system, and the message is generated by the ECU.

14. 1. A method comprising: receiving a message from the IC to be transmitted to an external destination; generating an error detection code for the message using first circuitry within the IC, the first circuitry complying with a safety standard; performing a task using the message and the error detection code using second circuitry in the IC, the second circuitry not complying with the safety standard; and transmitting the message and the error detecting code to the external destination after performing the task, wherein the first circuitry and the second circuitry are part of a communication channel that meets the safety standard.

15. Executing the task, 15. The method of claim 14, comprising encrypting the message and the error detecting code such that the message and the error detecting code are transmitted to the external destination in an encrypted state.

Images