CN115968470A

CN115968470A - Enhanced SPI communication protocol with reliability, security and fail-operational features

Info

Publication number: CN115968470A
Application number: CN202080102947.7A
Authority: CN
Inventors: 弗朗西斯科·冯斯·卢伊斯; 科斯塔斯·卡塔萨利斯
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-07-20
Filing date: 2020-07-20
Publication date: 2023-04-14
Also published as: WO2022017578A1

Abstract

The invention relates to a Serial Peripheral Interface (SPI) communication protocol. In particular, the present disclosure proposes an extension to the SPI protocol. To this end, the present disclosure accordingly proposes an apparatus and method for executing the extended SPI protocol. The device is configured to transmit and/or receive an extended SPI frame. The extended SPI frame comprises an SPI frame and additionally comprises one or more sets of bits that make up a header and/or trailer of the extended SPI frame. Thus, each of the sets of bits of the extended SPI frame corresponds to an extended SPI protocol capability.

Description

Enhanced SPI communication protocol with reliability, security and fail-operational features

Technical Field

The present disclosure relates to Serial Peripheral Interface (SPI) communication protocols. In particular, the present disclosure proposes an extension of the SPI protocol. To this end, the present disclosure accordingly proposes an apparatus and method for executing the extended SPI protocol. The extended SPI protocol is based on extended SPI frames and is backwards compatible with the current SPI protocol.

Background

The current SPI communication protocol has become a de facto standard in the industry due to its dominance as the solution of choice for inter-chip communication. For example, inter-chip communication between smart devices (e.g., microcontrollers, microprocessors, sensors, and actuators) that are physically distributed within the same electronic board or Printed Circuit Board (PCB). The SPI protocol is designed specifically for high speed short range serial data transmission, where any application running on top of the SPI protocol is distributed among several processing units-typically one master device (e.g., processor) and one or more slave devices (e.g., processors) -that need to exchange data to establish a bi-directional, full-duplex, synchronous communication link.

Indeed, today, the SPI protocol is largely built into many Microcontroller Unit (MCU) and System on Chip (SoC) devices widely used in different industries as a standard peripheral. For example, the SPI protocol is used to interconnect a Central Processing Unit (CPU) with external smart devices placed in the same electronic circuit or PCB, such as memory (e.g., flash memory), sensors (e.g., temperature sensors), and actuators (e.g., system base chips, power switching devices, etc.).

While the main functional/architectural features of conventional SPI protocols are static, i.e., they are predefined and fixed by the standard itself, some of their features are flexible and configurable by the user. For example, the data length (i.e., bits of a Transmit (TX)/Receive (RX) frame) or frequency (serial clock (SCLK)), polarity (clock polarity (CPOL)), and phase (clock phase (CPHA)) of the signals/waveforms involved in their physical interfaces are configurable.

The major features of the SPI protocol include:

master-slave model (MST-SLV)

Four-wire interface (Master out Slave in, MOSI), master In Slave Out (MISO), SCLK, and Slave Select (SSEL)).

Synchronous (SCLK) and time-deterministic communication

Serial interface, full duplex (MOSI, MISO)

Single Master (MST) to Single/Multi Slave (SLV) communication options (Point-to-Point and daisy-chained)

No need for Transceiver (TTL/CMOS logic level)

Designed for high speed short range communication

SPI protocol configurable features include:

variable data length (frame bit)

Variable transmission frequency (SCLK)

Configurable Polarity (CPOL) and phase (CPHA)

Conventional SPI peripherals are typically composed of a collection of configurable registers (i.e., control, data, and status registers) that are directly accessible by the system CPU (single core) or CPU (multi core) over the system bus and are typically mapped into the memory map of the MCU/SoC device. After the SPI peripheral is configured, data transfer may be performed.

Although the SPI protocol is widely used in the industry, it has a wide range of applications, but also has some limitations. In particular, it is not suitable for certain scenarios or use cases. Due to its simplicity, it does not fit into some more restrictive or more demanding use cases that require more stringent reliability and security features. This is the case, for example, in safety-critical or mission-critical applications. In fact, the fact that many embedded systems must coexist in very harsh and noisy environments can lead to potential problems with electromagnetic interference (EMI). EMI is composed of any unwanted, stray, conducted, or radiated power signal that may cause unacceptable degradation of system or device performance. When data is transferred end-to-end, EMI may negatively impact the signal or waveform of the SPI interface. Thus, EMI may cause misinterpretation of communication data or protocols (e.g., cosmic radiation in aerospace missions may cause single event disturbances — radiation induced errors in microelectronic circuits that may eventually change the state of a memory cell from a logic 1 to a logic 0, and vice versa), and may eventually cause system failure.

Therefore, there is a reason to improve the current SPI protocol.

Disclosure of Invention

Embodiments of the present invention are also based on the following considerations made by the inventors.

To be able to prevent, detect and correct some of the above mentioned potential communication disturbances of the current SPI protocol, specific reliability and security countermeasures, such as data integrity checks and/or high availability mechanisms, may be incorporated.

Currently, the SPI protocol specifies how SPI data frames (consisting of payload only) are transmitted from one end (master) to the other end (slave) in a synchronous (clock-based, bit-time) manner over TTL/CMOS logic levels (i.e.,

digital bits

1 or 0 encoded respectively according to a specific voltage level range) without requiring any specific protocol layering or transceivers. Further, the master device is a device that provides a clock signal and initiates each communication.

In addition to establishing a single communication link between a master device and a slave device over a four-wire SPI interface, conventional SPI protocols also enable one master device to simultaneously address multiple slave devices by establishing a communication bus. Effectively, a master device may be interconnected to a plurality of slave devices. In the case of managing multiple slave devices, such communication may be one of the following:

(i) Point-to-point, i.e. by handling several select lines from the master device, one for each of the slave devices.

(ii) Daisy-chain configurations affect slave devices in the same data transmission by composing SPI frames as a result of the addition of multiple words, each word associated with a slave device.

In addition, conventional SPI solutions are now integrated in MCU/SoC devices in dedicated SPI peripherals and directly solve the integration problem of SPI protocols in hardware with the help of digitally implemented SPI master and slave controllers. The SPI protocol ensures synchronous bidirectional transfer of data payloads from a master device to a slave device and vice versa, but does not provide any type of mechanism capable of checking the integrity of the data (payload) as it is transferred. Due to this fact, in case the SPI slave receives an SPI frame (payload) from the SPI master, and the SPI frame is damaged during transmission through the physical layer (e.g., due to external noise sources such as EMI or electrostatic discharge (ESD), voltage and current peaks due to inductive load switching, etc.), neither end has any error detection mechanism properly provided by the SPI protocol itself.

The main drawbacks of conventional SPI protocols and related schemes are the lack of reliability, safety, and/or fail operational features and/or countermeasures that make them unsuitable for safety-critical or mission-critical applications for which it is critical or error-prone. Conventional SPI protocol schemes either simply do not support any end-to-end (E2E) communication countermeasures to be ported to the SPI protocol.

In view of the foregoing problems and disadvantages, embodiments of the present invention are directed to improving conventional SPI protocols and related solutions. It is an object to provide an extended SPI protocol with additional features/capabilities, aimed at adapting the extended SPI protocol to a wider range of applications. That is, the goal is to extend the boundaries of the current SPI protocol. In particular, the new features/capabilities of the extended SPI protocol should provide reliability, safety, and/or fail-operational features and/or countermeasures.

Furthermore, embodiments of the present invention are directed to providing all of these new enhanced features/capabilities by being incorporated into the design and implementation of hardware (e.g., in silicon, as part of the SPI peripheral of a device such as an MCU/SoC). The operability of the new capability should be flexible and configurable to provide extended functionality as an SPI backward compatible solution. That is, it should be possible for all new capabilities of the extended SPI protocol to be enabled or disabled as needed, for example, by the user during SPI setup. Thus, if the user disables all enhanced capabilities of the extended SPI peripheral, the resulting SPI protocol should behave like a conventional SPI protocol, which is currently standardized and employed in, for example, MCU/SoC devices.

It is worth noting that both ends of the communication, the talker and the listener, i.e. the master and the slave, are configured with the same feature set in order to establish a communication link, as happens now with the SPI protocol, where each end can understand each other. The same concept should be applied to embodiments of the present invention, i.e., using the extended SPI protocol. In the case where one of the new capabilities is enabled, the capability should be identically configured on both ends, e.g., on the master and slave. In this sense, the extended SPI protocol should provide an evolution of the conventional SPI protocol principles, i.e. without modifying the essence of the conventional SPI communication protocol. Only the applicability of the SPI protocol should be extended, for example, by bringing a robust mechanism in the form of new features/capabilities that a user can configure in an extended SPI peripheral.

This object is achieved by the embodiments of the invention described in the appended independent claims. Advantageous realizations of embodiments of the invention are further defined in the dependent claims.

In summary, embodiments of the present invention propose to extend the set of capabilities of the conventional (legacy) SPI protocol in order to increase reliability and robustness for the extended SPI protocol. The objective is to enable the resulting extended SPI protocol to be used in more demanding application scenarios/domains where the conventional SPI protocol cannot withstand conditions of exposure to higher levels of noise, interference or disturbances. Therefore, the extended SPI protocol may be performed to ensure backward compatibility with the conventional SPI protocol.

A first aspect of the present invention provides a device for executing an extended SPI protocol, the device being configured to: transmitting and/or receiving an extended SPI frame, wherein the extended SPI frame comprises an SPI frame and additionally comprises one or more sets of bits constituting a header and/or a trailer of the extended SPI frame; and wherein each of the sets of bits of the extended SPI frame corresponds to an extended SPI protocol capability.

The extended SPI protocol is a communication protocol that is based on similar functionality as the conventional SPI protocol, but allows the use of extended SPI protocol capabilities. To this end, where one or more of the extended SPI protocol capabilities are enabled, the extended SPI protocol is implemented by using an extended SPI frame instead of an SPI frame (which corresponds to a conventional SPI frame of a conventional SPI protocol). Extended SPI protocol capabilities are capabilities or features not found in conventional SPI protocols. They may be specified by a set of bits that make up the end and/or head of the extended SPI frame. In particular, these capabilities enable reliability, safety, and/or fault operability and/or countermeasures, examples of which are described below.

By enabling the extended SPI protocol capability, new functionality is added compared to the conventional (legacy) SPI protocol, wherein these functionalities address the drawbacks of the conventional SPI protocol described above. In particular, the device of the first aspect allows the extended SPI protocol (due to the extension of the conventional SPI protocol) to be used for a wider range of applications. By extending a conventional SPI frame with a set of bits, i.e. by constituting a header and/or trailer of the extended SPI frame, new SPI protocol capabilities can be specified in a simple manner. Thus, these capabilities can be flexibly enabled and disabled to provide backward compatibility for conventional SPI protocols.

In one implementation of the first aspect, the device comprises a master device for executing the extended SPI protocol, the master device being configured to: adding the one or more bit sets to the SPI frame to form the extended SPI frame, sending the extended SPI frame to one or more slave devices for executing the extended SPI protocol, and receiving an extended SPI frame from the one or more slave devices; and/or the device comprises a slave device for executing the extended SPI protocol, the slave device being configured to: receive the extended SPI frame, obtain the one or more bit sets from the extended SPI frame, and perform one or more actions based on the obtained one or more bit sets, and also send the extended SPI frame to the master device.

For example, the device may include a master device and/or a slave device for inter-chip communication, e.g., in a device peripheral (extended SPI peripheral). The device may be a MCU or a SoC. However, the device may also be a master or a slave.

In one implementation of the first aspect, the header and/or the trailer of the extended SPI frame comprises one or more data fields; and each of the sets of bits is included in a data field.

In the following of the present disclosure, a reference to a data field means a reference to a set of bits included in the data field.

In one implementation of the first aspect, the device is further configured to: adding or obtaining a particular set of bits corresponding to a particular extended SPI protocol capability to or from the extended SPI frame if it is determined that the particular extended SPI protocol capability is enabled.

Thus, new functionality to extend the capabilities of the SPI protocol may be flexibly enabled or disabled.

In one implementation of the first aspect, the apparatus is further configured to: if no extended SPI protocol capability is enabled, then the SPI frame is sent and/or received instead of the extended SPI frame.

Thus, if all extended SPI protocol capabilities are disabled, then conventional SPI frames of the conventional SPI protocol may be exchanged. Thus, the extended SPI protocol is backward compatible with the conventional SPI protocol.

In particular, in addition to the extended SPI protocol capability, an advantageous aspect of embodiments of the present invention is that the resulting extended SPI protocol is backward compatible with current standardized SPI protocols. This means that in the device of the first aspect, e.g. in an MCU/SoC device, there may be an extended SPI peripheral, where all extended SPI protocol capabilities may be disabled, e.g. by software, to return to the conventional SPI protocol.

In one implementation of the first aspect, the one or more extended SPI protocol capabilities include one or more of: data integrity checking and/or error detection of the SPI frame; error correction of the SPI frame; an activity indicator of the master device executing the extended SPI protocol; a timestamp indicator of the SPI frame; a watchdog timer of the master device; frame redundancy and/or duplication of a plurality of master devices that redundantly implement the extended SPI protocol; frame redundancy and/or duplicate detection and elimination for a plurality of slave devices redundantly implementing the extended SPI protocol; an automatic failover mechanism for a plurality of master and slave devices executing the extended SPI protocol.

The above described implementations provide examples of new functionality provided by the extended SPI protocol capability. The extended SPI protocol capability primarily provides reliability, safety, and/or fault operability and/or countermeasures.

In one implementation of the first aspect, the data integrity check and/or error detection is based on parity bits, a checksum, a Cyclic Redundancy Check (CRC), or a hash calculation; and the bit set corresponding to the data integrity check and/or error detection includes the parity bit or includes a plurality of bits for the checksum or the CRC or the hash calculation, and is included in the frame end of the extended SPI frame.

In one implementation of the first aspect, the error correction is based on an error correction code; and the bit set corresponding to the error correction includes a plurality of bits indicating the error correction code and/or one or more check bits, and is included in the end of frame of the extended SPI frame.

In one implementation of the first aspect, the activity indicator is based on a counter; and the set of bits corresponding to the activity indicator includes a plurality of bits incremented for each extended SPI frame sent from the master device to the slave device executing the extended SPI protocol and is included in the frame header of the extended SPI frame.

In one implementation of the first aspect, the set of bits corresponding to the timestamp indicator includes a plurality of bits indicating a time at which the extended SPI frame is released by the master device executing the extended SPI protocol, and is included in the header of the extended SPI frame.

In one implementation of the first aspect, the watchdog timer is configured to trigger the slave device executing the SPI extension protocol to monitor whether the master device executes the SPI extension protocol at an expected pace and/or within an expected time window.

In one implementation of the first aspect, the frame redundancy and/or duplication detection and elimination is based on a sequence number or counter associated with the extended SPI frame; and the set of bits corresponding to the frame redundancy and/or duplicate detection and elimination includes a plurality of bits indicating the sequence number or counter and is included in the header of the extended SPI frame.

In one implementation of the first aspect, the automatic failover mechanism is adapted to transfer control of the SPI protocol to another device or to a second SPI physical channel when an error or failure in the performance of the extended SPI protocol is detected in the first SPI physical channel.

In an implementation manner of the first aspect, the apparatus further includes: an extended SPI parameter set configured to control and/or monitor the one or more extended SPI protocol capabilities.

The extended SPI parameter may be set/stored in the extended SPI register. Thus, a hardware implementation for enabling extended SPI capability is provided. By means of the extended SPI parameter, the extended SPI protocol capability can be flexibly enabled or disabled.

In one implementation of the first aspect, the set of extended SPI parameters is further configured to enable and/or disable the one or more extended SPI protocol capabilities.

Thus, the user can select the function that should be activated that extends the capabilities of the SPI protocol. Furthermore, backward compatibility with conventional SPI protocols may thus be enabled.

In an implementation manner of the first aspect, the extended SPI parameter set includes: one or more control parameters, wherein each control parameter is configured to enable at least one extended SPI protocol capability; and/or one or more status parameters, wherein each status parameter is configured to monitor a status of at least one extended SPI protocol capability.

In an implementation manner of the first aspect, the apparatus further includes: a set of SPI parameters independent of the set of extended SPI parameters, wherein each SPI parameter is configured to enable at least one legacy SPI protocol capability.

Thus, the conventional (legacy) SPI protocol capabilities can be controlled (enabled, disabled, monitored) independently of the (new) extended SPI protocol capabilities. This supports backward compatibility.

In an implementation manner of the first aspect, the apparatus further includes: a set of extended SPI logic blocks that are combined to support a Central Processing Unit (CPU) of the device to execute one or more enabled extended SPI protocol capabilities.

Thus, a hardware implementation is provided to enable/implement new features/capabilities of the extended SPI protocol.

In one implementation of the first aspect, the set of extended SPI logic blocks includes: one or more first extended SPI logic blocks, wherein each first extended SPI logic block is configurable by the CPU to perform at least one extended SPI peripheral capability.

Thus, a hardware implementation is provided for the flexible enabling and disabling of new features/capabilities of the extended SPI protocol by a device.

In an implementation manner of the first aspect, the set of extended SPI logic blocks further includes: one or more second extended SPI logic blocks, wherein each second extended SPI logic block is configured to interconnect two extended SPI peripherals such that the two SPI peripherals operate redundantly to transmit and receive the same extended SPI frame over two independent SPI physical channels that perform frame duplication and elimination for reliability policies, or if a first SPI physical channel is detected to be defective at any point in time during operation, said two SPI peripherals operate to transfer said transmission and reception of extended SPI frames from said first SPI physical channel to a second SPI physical channel at runtime as an automatic failover mechanism.

A second aspect of the present invention provides a method for executing an extended SPI protocol, the method comprising: transmitting and/or receiving an extended SPI frame, wherein the extended SPI frame comprises an SPI frame and additionally comprises one or more sets of bits constituting a header and/or a trailer of the extended SPI frame; and wherein each of the sets of bits of the extended SPI frame corresponds to an extended SPI protocol capability.

In one implementation of the second aspect, the method is performed by a master device for executing the extended SPI protocol, wherein the master device adds the one or more sets of bits to the SPI frame to form the extended SPI frame, sends the extended SPI frame to one or more slave devices for executing the extended SPI protocol, and may also receive extended SPI frames from the one or more slave devices; and/or the method is performed by a slave device for executing the extended SPI protocol, wherein the slave device receives the extended SPI frame, obtains the one or more bit sets from the extended SPI frame, and performs one or more actions based on the obtained one or more bit sets, and may also transmit an extended SPI frame to the master device.

In one implementation of the second aspect, the header and/or the trailer of the extended SPI frame comprises one or more data fields; and each of the sets of bits is included in a data field.

In one implementation form of the second aspect, the method further comprises: adding or obtaining a particular set of bits corresponding to a particular extended SPI protocol capability to or from the extended SPI frame if it is determined that the particular extended SPI protocol capability is enabled.

In one implementation form of the second aspect, the method further comprises: if no extended SPI protocol capability is enabled, then the SPI frame is sent and/or received instead of the extended SPI frame.

In one implementation of the second aspect, the one or more extended SPI protocol capabilities include one or more of: data integrity checking and/or error detection of the SPI frame; error correction of the SPI frame; an activity indicator of the master device executing the extended SPI protocol; a timestamp indicator of the SPI frame; a watchdog timer of the master device; frame redundancy and/or duplication of a plurality of master devices that redundantly execute the extended SPI protocol; frame redundancy and/or duplicate detection and elimination for a plurality of slave devices redundantly implementing the extended SPI protocol; an automatic failover mechanism for a plurality of master devices and slave devices executing the extended SPI protocol.

In one implementation of the second aspect, the data integrity check and/or error detection is based on parity bits, a checksum, a Cyclic Redundancy Check (CRC) or a hash calculation; and the set of bits corresponding to the data integrity check and/or error detection comprises the parity bit or a plurality of bits for the checksum or the CRC or the hash calculation and is included in the frame end of the extended SPI frame.

In one implementation of the second aspect, the error correction is based on an error correction code; and the set of bits corresponding to the error correction includes a plurality of bits indicating the error correction code and/or one or more check bits, and is included in the end of frame of the extended SPI frame.

In one implementation of the second aspect, the activity indicator is based on a counter; and the set of bits corresponding to the activity indicator includes a plurality of bits incremented for each extended SPI frame sent from the master device to the slave device executing the extended SPI protocol and is included in the header of the extended SPI frame.

In one implementation of the second aspect, the set of bits corresponding to the timestamp indicator includes a plurality of bits indicating a time at which the extended SPI frame is released by the master device executing the extended SPI protocol, and is included in the header of the extended SPI frame.

In one implementation of the second aspect, the watchdog timer is configured to trigger the slave device executing the extended SPI protocol to monitor whether the master device executes the extended SPI protocol at an expected pace and/or within an expected time window.

In one implementation of the second aspect, the frame redundancy and/or duplication detection and elimination is based on a sequence number or counter associated with the extended SPI frame; and the set of bits corresponding to the frame redundancy and/or duplicate detection and elimination includes a plurality of bits indicating the sequence number or counter and is included in the header of the extended SPI frame.

In one implementation of the second aspect, the automatic failover mechanism is adapted to transfer control of the SPI protocol to another device or a second SPI physical channel when an error or failure in performance of the extended SPI protocol is detected in the first SPI physical channel.

In one implementation form of the second aspect, the method further comprises: using an extended SPI parameter set to control and/or monitor the one or more extended SPI protocol capabilities.

In one implementation of the second aspect, the set of extended SPI parameters is further configured to enable and/or disable the one or more extended SPI protocol capabilities.

In one implementation of the second aspect, the extended SPI parameter set comprises: one or more control parameters, wherein each control parameter is configured to enable at least one extended SPI protocol capability; and/or one or more status parameters, wherein each status parameter is configured to monitor a status of at least one extended SPI protocol capability.

In one implementation form of the second aspect, the method further comprises: using a set of SPI parameters that is independent of the set of extended SPI parameters, wherein each SPI parameter is configured to enable at least one legacy SPI protocol capability.

In one implementation form of the second aspect, the method further comprises: a set of extended SPI logic blocks are used that are combined to support a Central Processing Unit (CPU) of the device in order to execute one or more enabled extended SPI protocol capabilities.

In one implementation of the second aspect, the set of extended SPI logic blocks comprises: one or more first extended SPI logic blocks, wherein each first extended SPI logic block is configurable by the CPU to perform at least one extended SPI peripheral capability.

In one implementation of the second aspect, the set of extended SPI logic blocks further comprises: one or more second extended SPI logic blocks, wherein each second extended SPI logic block is configured to interconnect two extended SPI peripherals such that the two SPI peripherals operate redundantly to send and receive the same extended SPI frame over two independent SPI physical channels that perform frame duplication and elimination for reliability policies, or if a first SPI physical channel is detected as defective at any point in time during operation, the two SPI peripherals operate to transfer the sending and receiving of extended SPI frames from the first SPI physical channel to a second SPI physical channel at runtime as an automatic failover mechanism.

The method of the second aspect enjoys all the advantages of the apparatus of the first aspect.

A third aspect of the invention provides a computer program comprising program code for performing the method according to the second aspect or any of its implementations when executed on a computer.

A fourth aspect of the invention provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to any of the second aspects or implementations thereof to be performed.

In summary, the above-described aspects and implementations propose to fill the above-described communication reliability gap of the conventional SPI protocol by extending the conventional SPI protocol with new functionality/capabilities that are intended to improve the reliability and security aspects of the extended SPI protocol itself. These new SPI protocol capabilities incorporated into the extended SPI protocol are specifically designed to target their correct operation in more severe cases (e.g., mission-critical and/or safety-critical applications). To some extent, the extended SPI protocol may be equipped with a consistent set of data protection mechanisms that may be carefully designed to detect and/or protect extended SPI protocol communications from many possible sources of failure, such as electromagnetic interference, electrostatic discharge, noise, or signal timing issues. Some of these new features may be found in packet-based network protocols and standards such as ISO 26262 (functional security), policies such as Frame Replication and Erasure for Reliability (FRER), or other communication algorithms such as error detection and correction codes.

It should be noted that all devices, elements, units and means described in the present application may be implemented as software or hardware elements or any kind of combination thereof. All steps performed by the various entities described in this application and the functions to be performed by the various entities described are intended to mean that the respective entity is adapted or configured to perform the respective steps and functions. Although in the following description of specific embodiments specific functions or steps performed by external entities are not reflected in the description of specific detailed elements of the entity performing the specific steps or functions, it should be clear to a skilled person that these methods and functions may be implemented in corresponding hardware or software elements or any kind of combination thereof.

Drawings

The above aspects and implementations will be explained in the following description of the embodiments with reference to the accompanying drawings, in which,

fig. 1 illustrates an apparatus for performing an extended SPI protocol according to an embodiment of the present invention.

Fig. 2 shows a conventional SPI frame compared to an extended SPI frame used in an embodiment of the present invention.

FIG. 3 illustrates an exemplary set of parameters/registers of an SPI peripheral as compared to the set of parameters/registers of an extended SPI peripheral used in embodiments of the present invention.

Fig. 4 illustrates an exemplary system architecture of the SPI protocol compared to that of the extended SPI protocol implemented in embodiments of the present invention.

Fig. 5 shows an example of a frame redundancy implementation by two extended SPI protocol channels used in an embodiment of the present invention.

Fig. 6 shows a decomposition of the data field of an extended SPI frame used in the embodiment of the present invention.

Fig. 7 shows an extended SPI (protocol) peripheral that may be embedded in a device such as an MCU or SoC.

Fig. 8 illustrates a method for performing the extended SPI protocol, according to an embodiment of the present invention.

Detailed Description

Fig. 1 shows an apparatus 100 according to an embodiment of the invention. Device 100 is configured to execute an extended SPI protocol that includes new (extended) features/capabilities compared to conventional SPI protocols. Device 100 may include a master device and/or a slave device that may execute the extended SPI protocol.

Specifically, device 100 is configured to transmit and/or receive an extended SPI frame 101. Specifically, if the device 100 includes a master device, the device 100 may transmit an extended SPI frame. If device 100 includes a slave device, device 100 may receive an extended SPI frame 101. If device 100 includes both a master device and a slave device and SPI protocol communication may be between the master device and the slave device, device 100 may send and receive SPI frames 101.SPI protocol communication, particularly between a master device and a slave device, may be performed in an SPI peripheral of device 100.

For example, device 100 may include a master device for executing an extended SPI protocol, wherein the master device is configured to add one or more sets of bits to SPI frame 102 to form extended SPI frame 101, and further to send extended SPI frame 101 to one or more slave devices for executing the extended SPI protocol. A master device may also receive an extended SPI frame 101 from one or more slave devices (e.g., one form per slave device). Additionally or alternatively, device 100 may include a slave device for executing an extended SPI protocol, wherein the slave device is configured to receive an extended SPI frame 101 and obtain one or more bit sets from the extended SPI frame 101. The slave device may also perform one or more actions based on the obtained one or more sets of bits. Further, the slave device may also be configured to transmit the extended SPI frame 101 to the master device.

Extended SPI frame 101 comprises SPI frame 102, i.e., SPI frame 102 (specifically the payload) used in the conventional SPI protocol, and additionally comprises one or more bit sets. These one or more bit sets constitute a header 103 and/or trailer 104 of extended SPI frame 101. That is, the extended SPI frame 101 may include one or more bit sets that constitute only the header 103 (without the trailer 104), or may include one or more bit sets that constitute only the trailer 104 (without the header 103), or may include a plurality of bit sets that constitute both the header 103 and the trailer 104. For example, the header 103 and/or trailer 104 may include one or more data fields, and each of the one or more sets of bits may be included in one or more of the data fields.

Further, each of the bit sets of extended SPI frame 101 corresponds to an extended SPI protocol capability. That is, each set of bits added to the header 103 and/or trailer may specify or enable an extended SPI protocol capability. Thus, different combinations of bit sets may be included in an extended SPI frame 101 in order to specify or enable various combinations of extended SPI protocol capabilities. Extended SPI protocol capability may also not be enabled at all. In this case, device 100 may send (e.g., a master device) and/or receive (e.g., a slave device) SPI frame 102 (of the conventional/legacy SPI protocol) instead of extended SPI frame 101. In other words, in this case, the SPI frame 102 transmitted/received includes neither the header 103 nor the trailer 104.

The device 100 may include a processor or processing circuitry (not shown) configured to perform, carry out, or initiate various operations of the device 100 described herein. The processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software. The hardware may include analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuit may include components such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a Digital Signal Processor (DSP), or a multi-purpose processor.

The device 100 may also include memory circuitry that stores one or more instructions that may be executed by the processor or by the processing circuitry, in particular under control of software. For example, the memory circuit may include a non-transitory storage medium storing executable software code that, when executed by a processor or processing circuit, causes various operations of the device 100 to be performed.

In one embodiment, the processing circuitry includes one or more processors and non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code that, when executed by one or more processors, causes the device 100 to perform, carry out, or initiate the operations or methods described herein.

Embodiments of the present invention, such as device 100, may be provided with extended SPI protocol capabilities (new features relative to the original SPI protocol) based on the following three aspects.

The first aspect relates to an extended SPI frame 101 (or frame format). In this regard, fig. 2 shows a conventional SPI frame (top) compared to an extended SPI frame 101 (bottom). To extend the SPI protocol, the extended SPI protocol capability considered in this disclosure may be added in a manner that affects the format of the SPI frame. In particular, to incorporate new functionality of the extended SPI protocol, embodiments of the present invention contemplate an extended SPI frame 101.

Currently, an SPI frame consists of only one block of data, which corresponds to the payload (see fig. 2, top), i.e. the original data based on a certain amount of bits transmitted in both directions (e.g. from master to slave over MOSI line and from slave to master over MISO line) between e.g. the master and the slave. Now, in extended SPI frame 101, this data payload 102 may be extended with some new data fields (including one or more bit sets) allocated in the header 103 and/or trailer 104 of extended SPI frame 101 (also shown at the bottom of fig. 2).

This means that a normal SPI frame of n bits may be extended with additional h bits (i.e., one or more of the above-described sets of bits) that may be placed before the payload 102 and/or additional t bits (i.e., one or more of the above-described sets of bits) that may be placed after the payload 102. The number of bits h and t, their location, and their meaning may be specific to each of the extended SPI protocol capabilities implemented. In other words, each of the new functions of the extended SPI protocol capability may require the addition of a certain number of bits, i.e., the header 103 and/or trailer 104 that make up the extended SPI frame 101. However, although some new capabilities may be deployed without affecting the SPI frame (i.e., there are no extra bits in both the header 103 and trailer 104 of the extended SPI frame 101), as explained later in the detailed description of each extended SPI protocol capability.

With respect to extended SPI frame 101 backward compatibility, the header 103 and trailer 104 (data fields thereof) may be structured in such a way that they are optional (as shown in fig. 2), which may depend on the set of configurable extended SPI protocol capabilities that are enabled or disabled. For example, by a user in software, such as by writing to one or more configuration registers of device 100 (e.g., in an extended SPI peripheral). In further detail, each of these extended SPI protocol capabilities may be enabled or disabled independently of one another. Thus, if all capabilities are disabled at the same time, the resulting SPI frame will be the original SPI frame (SPI frame 102) corresponding to the legacy SPI protocol, which consists only of the payload depicted in fig. 2. With this policy, backward compatibility of extended SPI frame 101 with respect to regular SPI frame 102 can be ensured.

A second aspect relates to the SPI parameter and SPI registers. In particular, the set of extended SPI parameters 301, 302 (e.g., set/stored in SPI registers) may be configured to control and/or monitor one or more extended SPI protocol capabilities. In this regard, FIG. 3 shows an exemplary set of SPI parameters/registers for a conventional SPI peripheral (left; i.e., for the conventional SPI protocol) as compared to a set of SPI parameters/registers for an extended SPI peripheral (right; i.e., for the extended SPI protocol).

From a logical or functional perspective, the management of all extended SPI protocol capabilities can be implemented in a flexible and extensible manner due to the desired backward compatibility described above. Thus, the SPI parameter/register set and/or memory map may be extended to enhance the SPI peripheral to an extended SPI peripheral. This means that if the conventional SPI protocol is handled by a set of control, data and status parameters/

registers

311, 312, this set of parameters/registers can be extended with some other control and status parameters/

registers

301, 302 to include controllability and observability aspects of all these new functions, as shown in fig. 3. These additional SPI parameters/

registers

301, 302 may be accessed by the system CPU of the device 100, for example, following exactly the same write and read procedures as the original SPI registers/

parameters

311, 312, changing only their physical addresses to access the correct SPI parameters/registers.

As shown in fig. 3, the extended SPI parameters/

registers

301, 302 of the extended SPI peripheral, which may be named extended control register (eCONTROL register) 302 and extended status register (esctatus register) 301, may be independent of legacy SPI parameters/registers 311, 312 (control register 311 and status register 312), which legacy SPI parameters/

registers

311, 312 may be identical and fully compatible with the SPI parameters/registers of the conventional SPI peripheral.

By configuring the eCONTROL parameter/register 302, the user can define which extended SPI protocol capabilities are enabled and, therefore, which data fields (sets of bits) are used for the header 103 and/or trailer 104 of the extended SPI frame 101 shown in fig. 2, i.e., which data fields are activated. This correspondingly extends the length of extended SPI frame 101. In case the user disables all enhanced SPI protocol capabilities through the eCONTROL parameter/register 302, the resulting SPI frame will match the regular SPI frame, i.e. without the header 103 and trailer 104, only with the payload 102, as shown in fig. 2. By enabling/configuring each extended SPI protocol capability, the header 103 and/or trailer 104 may be composed of specific data fields that include one or more sets of bits necessary for encoding related functions. Thus, the length of the header 103 and/or trailer 104 may depend on the set of capabilities that the user enables in each application use case.

Still with regard to SPI frame backwards compatibility, in the case of handling an extended version of an SPI peripheral, it is necessary to configure an additional set of SPI parameters/

registers

301, 302, while if extended SPI protocol capabilities are disabled, management of the SPI peripheral may continue through the conventional set of SPI parameters/

registers

311, 312. That is, the set of SPI parameters/

registers

311, 312 is independent of the set of extended SPI parameters/

registers

301, 302, wherein each SPI parameter/

register

311, 312 is configured to enable at least one legacy SPI protocol capability.

The third aspect relates to SPI logic and hardware circuitry. That is, the device 100 may include a set of extended SPI logic blocks 401, 402, where these

blocks

401, 402 may be combined to support a CPU403 of the device 100 to perform one or more of the enabled extended SPI protocol capabilities. In this regard, fig. 4 shows an exemplary system architecture (left) for a conventional SPI protocol compared to a system architecture (right) for an extended SPI protocol.

From a system architecture perspective, hardware circuitry may be modified to deploy SPI protocol communications based on the extended SPI frame 101 and the extended SPI register set or extended memory map used to set the

extended SPI parameters

301, 302.

In addition to the set of registers and the extended SPI frame 101 for implementing the capabilities of the extended SPI protocol, where the extended SPI frame 101 may be comprised of data fields collected in the header 103 and/or trailer 104 of the extended SPI frame 101-while the SPI frame 102 (payload) located intermediate the header 103 and trailer 104 maintains the same structure as a conventional standardized SPI frame-the system architecture of the extended SPI protocol may combine new functionality in hardware through one or more logic blocks 401, 402. These logic blocks 401, 402 may be responsible for implementing the new algorithms and may interact in one way or another with the legacy logic blocks of a conventional SPI peripheral to ensure backward compatibility. In particular, this may be ensured by integrating new logic blocks 401, 402 into the hardware design in a non-intrusive manner-in this sense, these logic blocks 401, 402 do not modify the expected behavior of conventional SPI protocol capabilities. To this end, the architecture design may proceed as described below (and as shown in FIG. 4).

Currently, any conventional SPI peripheral (shown in fig. 3, left side) of an MCU/SoC device may be accessed by a system CPU (see fig. 4, left side) by means of read and write commands addressing different SPI parameters/registers for each instance of the SPI peripheral that is present in the MCU/SoC device and mapped in the full memory layout of the MCU/SoC device. Now, these accesses can remain the same for the extended SPI peripheral (see fig. 4, right side) of the device 100, the only difference being that the set of SPI parameters/registers present in the extended SPI peripheral consists of some more SPI parameters/registers 301, 302 (see fig. 3, right side) due to the increased capabilities of the (extended) SPI protocol that can be configured.

With respect to hardware implementations of these extended SPI protocol capabilities, the size of the extended SPI peripherals may grow with some more logic blocks 401, 402, which logic blocks 401, 402 may be organized into two different types of modules: a first extension logic block 401 (eX) for each extension SPI # X peripheral (corresponding to an extension SPI capability), and a second extension logic block 402 (eXY) for interconnecting two extension SPI peripherals # X and # Y (corresponding to two different SPI protocol capabilities) with a redundancy function activated as one of the possible extension SPI protocol capabilities described later in this document. That is, each first extended SPI logic block 401 may be configured by the CPU403 to perform at least one extended SPI protocol capability. Further, each second extended SPI logic block 402 may be configured to interconnect two extended SPI peripherals. Fig. 4 illustrates this concept in a graphical view.

Notably, in the event that the redundant functionality of the two extended SPI peripherals # X and # Y is disabled, from a functional perspective, access to the second logic block 402 (eXY) may be bypassed and the two extended SPI peripherals will remain operating independently of each other.

All of these features may be implemented by functional blocks within the device 100 (e.g., MCU/SoC device) corresponding to the controller or engine responsible for handling each of the capabilities provided in the new extended SPI protocol.

In summary, combining the above three aspects, an extended SPI peripheral/protocol may be implemented, which ensures backward compatibility with conventional SPI peripherals/protocols.

Examples of enhancing the SPI protocol to the extended SPI capability of the extended SPI protocol are presented below to enable its use in mission critical and high availability scenarios where conventional SPI protocols do not fit.

In general, embodiments of the invention may include adding the following enhancements to conventional SPI protocol capabilities (extended SPI protocol capabilities):

data integrity checking and/or error detection of spi frame 102.

Error correction of spi frame 102.

3. An activity indicator of a master device executing an extended SPI protocol.

A timestamp indicator of spi frame 102.

5. A watchdog timer of the master device.

6. Redundancy performs frame redundancy and/or replication of multiple master devices that extend the SPI protocol.

7. Redundancy performs frame redundancy and/or duplicate detection and elimination for multiple slave devices that extend the SPI protocol.

8. An automatic failover mechanism for multiple master and slave devices that implement the extended SPI protocol.

Not all of these features are currently considered in the conventional SPI protocol. Embodiments of the present invention are based on integrating these features into the extended SPI protocol in order to provide an enhanced version that can withstand harsh environments or mission critical applications. The technical details of relevant extended sPI protocol capabilities are presented below.

1. Data integrity checking as an error detection mechanism: this feature includes integrating a mechanism in the extended SPI communication protocol that can detect errors if an SPI frame 102 (payload) transmitted by a sender (SPI master) does not match an SPI frame 102 received by a receiver (SPI slave). Some examples of algorithms that can be combined as error detection codes in the enhanced SPI protocol are: parity bits, checksums, cyclic Redundancy Check (CRC), or any other hash calculation. The size of this data field in the enhancement frame may extend from 1 single bit in the case of parity bits to 8 or 16 bits of a CRC or hash, for example. For functional reasons (i.e., the data field cannot be calculated unless a complete data frame is received), the data field may be allocated in the trailer 104 of the extended SPI frame 101.

2. Error correction mechanisms (detecting and correcting certain types of errors): in addition to an error detection mechanism such as CRC, another protection mechanism can be integrated in the enhanced SPI protocol that is capable of not only detecting errors but also correcting errors. I.e. Error Correction Codes (ECC) for controlling errors in data over unreliable or noisy communication channels. The basic principle of ECC is to add redundant bits in the data message to be transmitted (here, the SPI frame 102) to help the receiver (e.g., the SPI slave) to find out the true message encoded by the transmitter (e.g., the SPI master). Redundancy allows the receiver to detect a limited number of errors that may occur anywhere in the message and correct them, typically without retransmission. For example, hamming codes are a family of linear error correcting codes that can detect up to 2 bit errors or correct 1 bit errors without detecting uncorrected errors.

Unlike error detection codes, error Correction Codes (ECCs) allow not only detection of certain types of errors, but also repair of these errors in certain situations. This feature may also be deployed in the extended SPI protocol, particularly in use cases oriented to high availability or fail-operational applications.

For example, hamming (7, 4) is a linear error correcting code that encodes four bits of data into seven bits by adding three parity bits. That is, the hamming code adds three additional check bits for every four data bits of the message, and the algorithm can correct any single bit error, or detect all single and two bit errors. In other words, the minimum hamming distance between any two correct codewords is 3, and a received word can be decoded correctly if it is at most 1 away from the codeword sent by the transmitter. This means that for the case of transmission media where burst errors do not occur, the hamming (7, 4) code is valid (since the medium must be extremely noisy for flipping two of the seven bits). In general, the size of the ECC data field in the extended SPI frame 101 may be 8 bits or 16 bits, and for functional reasons (i.e., the data field cannot be calculated unless the complete extended SPI frame 101 is received), the data field may be allocated in the trailer 104 of the extended frame.

3. Activity indicator: an activity indicator is a mechanism used in applications where the receiver (e.g., here an SPI slave) needs to know the availability and correct operation of the transmitter (e.g., here an SPI master) by scheduling periodic reception of certain frames, where it needs to check that the received frames are fresh (new, unlike the previous frame) only to prove that the transmitter is not down/off/corrupted, but remains active in normal execution. This feature is particularly useful in functional security applications where the slave monitors the correct operation of the host or master processor.

One example of an algorithmic implementation is to simply add an activity counter field to the enhanced SPI frame 101 that includes a cyclic n-bit counter that can be incremented on each transmission request by the transmitter and checked at the receiver end. The size of this counter may typically be 4 or more bits and this field may be allocated in the header 103 of the extended SPI frame 101 for functional reasons (i.e. in case the active counter is found to be defective, the processing of the SPI frame 102 (payload) may be skipped and the SPI frame may be discarded, while the receiver will react to this by triggering/activating some fail-safe or safe operation response).

4. Timestamp indicator: in some applications, particularly in time sensitive applications, it may be beneficial to know the exact system time that is normally running in the master device, so that the slave devices perform certain operations in a synchronized manner. In this case, a data field having a corresponding time stamp related to the time when the transmitter releases the SPI frame 102 may be appended to the extended SPI frame 101. To implement this feature in logic, the SPI peripheral may be provided with access to a system timer, e.g., of the MCU/SoC.

The size of this data field in extended SPI frame 101 may depend on the time accuracy of the application and the granularity of the system clock of the transmitter. This data field may typically be placed in the header 103 of the extended SPI frame 101.

5. Watchdog timer: in functional security applications driven by time sensitive conditions, an external watchdog mechanism is typically used in the slave device in order to monitor that the tasks of the master device are performed correctly. In this case, with the aid of the synchronization extension SPI frame 101 sent by the master device, the slave device can check whether the master device is operating at the expected pace of receiving the extension SPI frame 101 within the expected time window in the case of the watchdog window mode or before the timeout expires in the case of the watchdog timeout mode. If an extended SPI frame 101 is not received in the correct time slot, the slave will trigger a security response.

Notably, this extended SPI protocol capability can be implemented without impacting the extended SPI frame length, but only by adding logic and configuration parameters/registers in the enhanced SPI hardware peripherals.

In addition to the use of separate SPI peripherals, the extended SPI protocol allows two of these extended SPI peripherals to be interconnected to work together in redundant communications. To this end, two independent extended SPI peripherals of the device 100 (e.g., MCU/SoC) may be selected and configured in dual mode by linking them via some specific logic combined in hardware, as shown in fig. 4. The next two features 6 and 7 relate to this dual SPI configuration.

6. Frame redundancy and replication: the scope of application of the conventional SPI protocol does not cover any type of data transmission redundancy strategy-a feature particularly needed in high availability time sensitive systems where backward retransmission of data frames is not an option in case of failure of the first attempt. If the channel is corrupted and the transmitted data sent by the sender does not reach the receiver, or if the data is received but corrupted, in time-critical or fail-operational applications, it is required to either have redundant channels that fail at different times, thereby skipping the single failure that causes the system failure, or to trigger a fail/fail-safe reaction mechanism in real time and to ensure that a time-deterministic response or fail-over reaction occurs within a timeout (e.g., activating certain degraded operating modes or fail-safe modes). This aspect may be considered in the extended SPI protocol set forth in this disclosure.

Certain applications require the implementation of redundant communication channels in order to transmit the same data frames over two independent channels to be reliable for a single source of failure, e.g., to ensure that data frames transmitted from a master to a slave arrive at the slave, even when one of the E2E channels is defective, thereby operating a solution for the failure. In this disclosure, this process may affect the extended SPI frame 101 format. Specifically, a sequence counter or sequence number 501 (data field) may be added to the extended SPI frame 101 to identify duplicate (e.g., duplicate) frames from the device and to eliminate one or more of the duplicate frames when two or more redundant SPI channels are not defective. The sequence number or size of the counter 501 may be typically 4 bits or more, and the data field may be allocated in the header 103 of the extended SPI frame. This sequence counter or sequence number 501 is shown in an extended SPI frame 1 in fig. 5.

In addition to the extended SPI frame 101, with respect to hardware implementation, it is beneficial to deploy a logic block 402 (see, e.g., fig. 4), which logic block 402 is responsible for interconnecting two independent extended SPI peripherals to operate in a redundant manner when this feature is enabled. When configured for this purpose, this additional logic block 402 may establish a bridge between the two extended SPI peripherals # X and # Y (see, e.g., logic block 402 (eXY) in fig. 5). For example, if the feature is disabled by configuring the relevant parameters/registers, the two SPI channels may be disconnected again and may operate independently of each other without any kind of physical relationship. An example of the topology of this scheme is shown in figure 5.

In FIG. 5, in particular, two devices 100, one master device 100\ a and one slave device 100 \\ b, are shown in accordance with an embodiment of the present invention. Both devices 100\ua and 100_b are configured to transmit and receive an extended SPI frame 101 from each other. The extended SPI frame 101 may include a sequence counter or sequence number 501. Further, both devices 100\ua and 100_b are provided with a CPU403 and logical blocks 401, 402 (as shown in fig. 4), and may set/maintain registers/parameters 301, 302 (as shown in fig. 3).

7. Automatic failover mechanism: this feature, which is seamlessly linked with the previous feature, may include a process by which the primary SPI subsystem may automatically transfer control to the secondary SPI subsystem when an error or failure is detected by the primary SPI subsystem in order to minimize failover time. This extended SPI protocol capability may be implemented without affecting the extended SPI frame 101 format or length, but may be implemented by adding only some logic blocks 402 (see, e.g., block 402 (eXY) in fig. 4) and configuration parameters/registers in the enhanced SPI hardware peripheral.

As a summary of the seven extended SPI protocol capabilities (features) described above, fig. 6 shows a possible decomposition of the data fields (i.e., bit sets) included in the extended SPI frame 101 previously introduced in fig. 2. The extended SPI frame 101 shown in fig. 6 includes all the sets of bits required to implement all the feature sets simultaneously. This is the set of bits of the activity indicator 601 (or counter), the set of bits of the timestamp 602, the set of bits of the watchdog timer 603 (watchdog command), and the set of bits for data integrity checking and/or error detection 604 (here CRC) and/or for error correction 604 (here ECC).

Finally, for all of these seven extended SPI protocol capabilities, there may be at least one control bit called "enable/disable" in each feature in the eCONTROL register 302 (see fig. 3) that may be used to activate or deactivate its associated SPI protocol capability, depending on the expected backward compatibility. For example, the enhancement function can only be enabled and run when the bit is set to "1". Thus, if the user disables some of the extended SPI protocol capabilities, the affected data fields (bit sets) linked to this feature may automatically disappear from the extended SPI frame 101, or from the header 103 or trailer 104.

FIG. 7 illustrates a particular implementation example according to an embodiment of the invention. In particular, it is contemplated that a new IP core or peripheral called "enhanced SPI or extended SPI" may be allocated within any next generation chip that is planned to be built. The extended SPI core may include extended SPI registers 301, 302 of the extended SPI peripherals shown in fig. 3, i.e., may include one or more eCONTROL registers 302 and one or more eSTATUS registers 301. In addition, the extended SPI core may include legacy SPI control registers 311 and status registers 312, which may be identical and fully compatible with control registers and status registers of conventional SPI peripherals. For example, chips for the automotive market. Such a new extended SPI peripheral may be interconnected to the system bus of the MCU or SoC device so as to be accessible by the multi-core processor instantiated therein.

FIG. 8 illustrates a method 800 according to an embodiment of the invention. Method 800 may be performed by device 100. Method 800 includes step 801 of transmitting and/or receiving an extended SPI frame 101. Extended SPI frame 101 includes SPI frame 102 and additionally includes one or more sets of bits that make up a header 103 and/or trailer 104 of extended SPI frame 101. Thus, each of the bit sets of extended SPI frame 101 corresponds to (802) an extended SPI protocol capability.

The invention has been described in connection with various embodiments and implementations as examples. However, other variations can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the independent claims. In the claims as well as in the specification, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A device (100) for executing an extended serial peripheral interface, SPI, protocol, the device (100) being configured to:

transmitting and/or receiving an extended SPI frame (101), wherein said extended SPI frame (101) comprises an SPI frame (102) and additionally comprises one or more sets of bits constituting a header (103) and/or a trailer (104) of said extended SPI frame (101); and

wherein each of the sets of bits of the extended SPI frame (101) corresponds to an extended SPI protocol capability.

2. The apparatus (100) of claim 1, wherein:

the device (100) comprises a master device for executing the extended SPI protocol, the master device being configured to: adding the one or more bit sets to the SPI frame (102) to form the extended SPI frame (101), sending the extended SPI frame (101) to one or more slave devices for executing the extended SPI protocol, and receiving an extended SPI frame (101) from the one or more slave devices; and/or

The device (100) comprises a slave device for executing the extended SPI protocol, the slave device being configured to: receiving the extended SPI frame (102), obtaining the one or more sets of bits from the extended SPI frame (101), and performing one or more actions based on the obtained one or more sets of bits, and also sending the extended SPI frame (101) to the master device.

3. The apparatus (100) of claims 1 to 2, wherein:

the header (103) and/or trailer (104) of the extended SPI frame (101) comprising one or more data fields; and

each of the sets of bits is included in a data field.

4. The device (100) according to one of claims 2 to 3, further configured to:

adding or obtaining a particular set of bits corresponding to a particular extended SPI protocol capability to or from the extended SPI frame (101) if it is determined that the particular extended SPI protocol capability is enabled.

5. The device (100) according to one of claims 1 to 4, configured to:

transmitting and/or receiving the SPI frame (102) instead of the extended SPI frame (101) if no extended SPI protocol capability is enabled.

6. The device (100) according to one of claims 1 to 5, wherein the one or more extended SPI protocol capabilities comprise one or more of:

-data integrity checking and/or error detection (604) of the SPI frame (102);

-error correction (604) of the SPI frame (102);

-an activity indicator (601) of the master device executing the extended SPI protocol;

-a timestamp indicator (602) of the SPI frame (102);

-a watchdog timer (603) of the master device;

-frame redundancy and/or duplication of a plurality of master devices redundantly performing the extended SPI protocol;

-frame redundancy and/or duplicate detection and elimination for a plurality of slave devices redundantly performing the extended SPI protocol;

-an automatic failover mechanism of a plurality of master and slave devices executing the extended SPI protocol.

7. The apparatus (100) of claim 6, wherein:

the data integrity check and/or error detection (604) is based on parity bits, a checksum, a cyclic redundancy check, CRC, or a hash calculation; and

the set of bits corresponding to the data integrity check and/or error detection (604) comprises the parity bits or a plurality of bits for the checksum or the CRC or the hash calculation and is included in the trailer (104) of the extended SPI frame (101).

8. The apparatus (100) according to claim 6 or 7, wherein:

the error correction (604) is based on an error correction code; and

the set of bits corresponding to the error correction (604) includes a plurality of bits and/or one or more check bits indicative of the error correction code and is included in the trailer (104) of the extended SPI frame (101).

9. The apparatus (100) according to one of claims 6 to 8, wherein:

the activity indicator is based on a counter; and

the set of bits corresponding to the activity indicator (601) includes a plurality of bits incremented for each extended SPI frame (101) sent from the master device to the slave device executing the extended SPI protocol and is included in the header (103) of the extended SPI frame (101).

10. The apparatus (100) according to one of claims 6 to 9, wherein:

the set of bits corresponding to the timestamp indicator (602) includes a plurality of bits indicating a time at which the extended SPI frame (101) is released by the master device executing the extended SPI protocol, and is included in the frame header of the extended SPI frame (101).

11. The apparatus (100) according to one of claims 6 to 10, wherein:

the watchdog timer (603) is used to trigger the slave device executing the extended SPI protocol to monitor whether the master device executes the extended SPI protocol at an expected pace and/or within an expected time window.

12. The apparatus (100) according to one of claims 6 to 11, wherein:

the frame redundancy and/or duplication detection and elimination is based on a sequence number or counter (501) associated with the extended SPI frame (101); and

the set of bits corresponding to the frame redundancy and/or duplicate detection and elimination includes a plurality of bits indicating the sequence number or counter (501) and is included in the header (103) of the extended SPI frame (101).

13. The apparatus (100) according to one of claims 6 to 12, wherein:

the automatic failover mechanism is adapted to transfer control of the SPI protocol to another device or to a second SPI physical channel when an error or failure in the performance of the extended SPI protocol is detected in the first SPI physical channel.

14. The apparatus (100) according to one of claims 1 to 13, further comprising:

a set of extended SPI parameters (301, 302) configured to control and/or monitor the one or more extended SPI protocol capabilities.

15. The apparatus (100) of claim 14, wherein:

the set of extended SPI parameters (301, 302) is further configured to enable and/or disable the one or more extended SPI protocol capabilities.

16. The device (100) according to claim 14 or 15, wherein the extended SPI parameter set comprises:

one or more control parameters (302), wherein each control parameter (302) is configured to enable at least one extended SPI protocol capability; and/or

One or more status parameters (301), wherein each status parameter (301) is configured to monitor a status of at least one extended SPI protocol capability.

17. The apparatus (100) according to one of claims 14 to 16, further comprising:

a set of SPI parameters (311, 312) independent of the set of extended SPI parameters (301, 302), wherein each SPI parameter (311, 312) is configured to enable at least one legacy SPI protocol capability.

18. The apparatus (100) according to one of claims 1 to 17, further comprising:

a set of extended SPI logic blocks (401, 402) combined to support a central processing unit CPU (403) of the device (100) to perform one or more enabled extended SPI protocol capabilities.

19. The device (100) according to claim 17 or 18 and according to one of claims 13 to 16, wherein the set of extended SPI logic blocks (401, 402) comprises:

one or more first extended SPI logic blocks (401), wherein each first extended SPI logic block (401) is configurable by the CPU to perform at least one extended SPI peripheral capability.

20. The device (100) of claim 19, wherein the set of extended SPI logic blocks (401, 402) further comprises:

one or more second extended SPI logic blocks (402), wherein each second extended SPI logic block (402) is configured to interconnect two extended SPI peripherals such that the two SPI peripherals operate redundantly to send and receive the same extended SPI frame (101) over two independent SPI physical channels that perform the frame copying and elimination for reliability policies, or, if a first SPI physical channel is detected as defective at any point in time during operation, the two SPI peripherals operate to transfer the sending and receiving of extended SPI frames (101) from the first SPI physical channel to a second SPI physical channel at runtime as an automatic failover mechanism.

21. A method (800) for performing an extended serial peripheral interface, SPI, protocol, the method (800) comprising:

transmitting and/or receiving (801) an extended SPI frame (101), wherein the extended SPI frame (101) comprises an SPI frame (102) and additionally comprises one or more sets of bits constituting a header (103) and/or a trailer (104) of the extended SPI frame (101); and

wherein each of the bit sets of the extended SPI frame (101) corresponds (802) to an extended SPI protocol capability.

22. A computer program comprising program code for performing the method (800) according to claim 21 when executed on a computer.