Patent Grant
10931476
As electronic components decrease in size, and as performance expectations increase, more components are included in previously un-instrumented or less-instrumented devices. In some settings, the communication infrastructure used to exchange signals between these components (e.g., in a vehicle) has required thick and heavy bundles of cables.
Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, not by way of limitation, in the figures of the accompanying drawings.
Disclosed herein are systems and techniques for sending content protected digital data (e.g., digital audio) over synchronous data networks (SDNs).
In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized, and structural or logical changes may be made, without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense.
Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed and/or described operations may be omitted in additional embodiments.
For the purposes of the present disclosure, the phrase “A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).
Various components may be referred to or illustrated herein in the singular (e.g., a “processor,” a “peripheral device,” etc.), but this is simply for ease of discussion, and any element referred to in the singular may include multiple such elements in accordance with the teachings herein.
The description uses the phrases “in an embodiment” or “in embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous. As used herein, the term “circuitry” may refer to, be part of, or include an application-specific integrated circuit (ASIC), an electronic circuit, and optical circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware that provide the described functionality.
The master node 102-1 may communicate with the slave nodes 102-2 over a two-wire bus 106. The bus 106 may include different two-wire bus links between adjacent nodes along the bus 106 to connect the nodes along the bus 106 in a daisy-chain fashion. For example, as illustrated in
The master node 102-1 may include one or more transceivers for communication over the bus 106 (as discussed below), and content protection circuitry. The content protection circuitry may perform any of the content protection operations disclosed herein (e.g., decryption, encryption, providing relevant supporting data to the transceiver(s), etc.). In some embodiments, the transceiver(s) of the master node 102-1 may be included in a single die, and the content protection circuitry may be included in a different die; in some such embodiments, the different dies may be included in a single multi-chip package (MCP) in the master node 102-1. In other embodiments, the transceiver(s) of the master node 102-1 and the content protection circuitry may be included in a single die, or distributed across more than two dies packaged in any desired manner.
A slave node 102-2 may include one or more transceivers for communication over the bus 106 (as discussed below), and content protection circuitry. The content protection circuitry may perform any of the content protection operations disclosed herein (e.g., decryption, encryption, providing relevant supporting data to the transceiver(s), etc.). In some embodiments, the transceiver(s) of the slave node 102-2 may be included in a single die, and the content protection circuitry may be included in a different die; in some such embodiments, the different dies may be included in a single MCP in the slave node 102-2. In other embodiments, the transceiver(s) of the slave node 102-2 and the content protection circuitry may be included in a single die, or distributed across more than two dies packaged in any desired manner.
The host 110 may include a processor that programs the master node 102-1, and acts as the originator and recipient of various payloads transmitted along the bus 106. In some embodiments, the host 110 may be or may include a microcontroller, for example. In particular, the host 110 may be the master of Inter-Integrated Circuit Sound (I2S) communications that happen along the bus 106. The host 110 may communicate with the master node 102-1 via an I2S/Time Division Multiplex (TDM) bus and/or an Inter-Integrated Circuit (I2C) bus. In some embodiments, communications between the host 110 and the master node 102-1 may not be encrypted; instead, these communications may be protected from unauthorized access by embedding the relevant bus lines between layers of a printed circuit board (PCB), or otherwise making physical access difficult. In some embodiments, the master node 102-1 may be a transceiver (e.g., the node transceiver 120 discussed below with reference to
The master node 102-1 may generate “downstream” signals (e.g., data signals, power signals, etc., transmitted away from the master node 102-1 along the bus 106) and receive “upstream” signals (e.g., transmitted toward the master node 102-1 along the bus 106). The master node 102-1 may provide a clock signal for synchronous data transmission over the bus 106. As used herein, “synchronous data” may include data streamed continuously (e.g., audio signals) with a fixed time interval between two successive transmissions to/from the same node along the bus 106. In some embodiments, the clock signal provided by the master node 102-1 may be derived from an I2S input provided to the master node 102-1 by the host 110. A slave node 102-2 may be an addressable network connection point that represents a possible destination for data frames transmitted downstream on the bus 106 or upstream on the bus 106. A slave node 102-2 may also represent a possible source of downstream or upstream data frames. The system 100 may allow for control information and other data to be transmitted in both directions over the bus 106 from one node to the next. One or more of the slave nodes 102-2 may also be powered by signals transmitted over the bus 106.
In particular, each of the master node 102-1 and the slave nodes 102-2 may include a positive upstream terminal (denoted as “AP”), a negative upstream terminal (denoted as “AN”), a positive downstream terminal (denoted as “BP”), and a negative downstream terminal (denoted as “BN”). The positive and negative downstream terminals of a node may be coupled to the positive and negative upstream terminals of the adjacent downstream node, respectively. As shown in
As discussed in detail below, the master node 102-1 may periodically send a synchronization control frame downstream, optionally along with data intended for one or more of the slave nodes 102-2. For example, the master node 102-1 may transmit a synchronization control frame every 1024 bits (representing a superframe) at a frequency of 48 kHz, resulting in an effective bit rate on the bus 106 of 49.152 Mbps. Other rates may be supported, including, for example, 44.1 kHz. The synchronization control frame may allow the slave nodes 102-2 to identify the beginning of each superframe and also, in combination with physical layer encoding/signaling, may allow each slave node 102-2 to derive its internal operational clock from the bus 106. The synchronization control frame may include a preamble for signaling the start of synchronization, as well as control fields that allow for various addressing modes (e.g., normal, broadcast, discovery), configuration information (e.g., writing to registers of the slave nodes 102-2), conveyance of I2C information, remote control of certain general-purpose input/output (GPIO) pins at the slave nodes 102-2, and other services. A portion of the synchronization control frame following the preamble and the payload data may be scrambled to reduce the likelihood that information in the synchronization control frame will be mistaken for a new preamble, and to flatten the spectrum of related electromagnetic emissions.
The synchronization control frame may get passed between slave node 102-2 (optionally along with other data, which may come from the master node 102-1 but additionally or alternatively may come from one or more upstream slave nodes 102-2 or from a slave node 102-2 itself) until it reaches the last slave node 102-2 (i.e., the slave node 2 in
In some embodiments, one or more of the slave nodes 102-2 in the system 100 may be coupled to and communicate with a peripheral device 108. For example, a slave node 102-2 may be configured to read data from and/or write data to the associated peripheral device 108 using I2S, pulse density modulation (PDM), TDM, and/or I2C protocols, as discussed below. In some embodiments, the data communicated between the slave nodes 102-2 and their associated peripheral devices 108 may not be encrypted; instead, these communications may be protected from unauthorized access by embedding the relevant bus lines between layers of a PCB, or otherwise making physical access difficult. Although the “peripheral device 108” may be referred to in the singular herein, this is simply for ease of discussion, and a single slave node 102-2 may be coupled with zero, one, or more peripheral devices. Examples of peripheral devices that may be included in the peripheral device 108 may include a digital signal processor (DSP), a field programmable gate array (FPGA), an ASIC, an analog to digital converter (ADC), a digital to analog converter (DAC), a codec, a microphone, a microphone array, a speaker, an audio amplifier, a protocol analyzer, an accelerometer or other motion sensor, an environmental condition sensor (e.g., a temperature, humidity, and/or gas sensor), a wired or wireless communication transceiver, a display device (e.g., a touchscreen display), a user interface component (e.g., a button, a dial, or other control), a camera (e.g., a video camera), a memory device, or any other suitable device that transmits and/or receives data. A number of examples of different peripheral device configurations are discussed in detail herein.
In some embodiments, the peripheral device 108 may include any device configured for I2S communication; the peripheral device 108 may communicate with the associated slave node 102-2 via the I2S protocol. In some embodiments, the peripheral device 108 may include any device configured for I2C communication; the peripheral device 108 may communicate with the associated slave node 102-2 via the I2C protocol. In some embodiments, a slave node 102-2 may not be coupled to any peripheral device 108.
A slave node 102-2 and its associated peripheral device 108 may be contained in separate housings and coupled through a wired or wireless communication connection or may be contained in a common housing. For example, a speaker connected as a peripheral device 108 may be packaged with the hardware for an associated slave node 102-2 (e.g., the node transceiver 120 discussed below with reference to
As discussed above, the host 110 may communicate with and control the master node 102-1 using multi-channel I2S and I2C communication protocols. For example, the host 110 may transmit data via I2S to a frame buffer (not illustrated) in the master node 102-1, and the master node 102-1 may read data from the frame buffer and transmit the data along the bus 106. Analogously, the master node 102-1 may store data received via the bus 106 in the frame buffer, and then may transmit the data to the host 110 via I2S.
Each slave node 102-2 may have internal control registers that may be configured by communications from the master node 102-1. A number of such registers are discussed in detail below. Each slave node 102-2 may receive downstream data and may retransmit the data further downstream. Each slave node 102-2 may receive and/or generate upstream data and/or retransmit data upstream and/or add data to and upstream transaction.
Communications along the bus 106 may occur in periodic superframes. Each superframe may begin with a downstream synchronization control frame; be divided into periods of downstream transmission (also called “downstream portions”), upstream transmission (also called “upstream portions”), and no transmission (where the bus 106 is not driven); and end just prior to transmission of another downstream synchronization control frame. The master node 102-1 may be programmed (by the host 110) with a number of downstream portions to transmit to one or more of the slave nodes 102-2 and a number of upstream portions to receive from one or more of the slave nodes 102-2. Each slave node 102-2 may be programmed (by the master node 102-1) with a number of downstream portions to retransmit down the bus 106, a number of downstream portions to consume, a number of upstream portions to retransmit up the bus 106, and a number of upstream portions in which the slave node 102-2 may transmit data received from the slave node 102-2 from the associated peripheral device 108. Communication along the bus 106 is discussed in further detail below with reference to
Each of the master node 102-1 and the slave nodes 102-2 may include a transceiver to manage communication between components of the system 100.
The node transceiver 120 may include an upstream differential signaling (DS) transceiver 122 and a downstream DS transceiver 124. The upstream DS transceiver 122 may be coupled to the positive and negative upstream terminals discussed above with reference to
The upstream DS transceiver 122 and the downstream DS transceiver 124 may communicate with bus protocol circuitry 126, and the bus protocol circuitry 126 may communicate with a phased locked loop (PLL) 128 and voltage regulator circuitry 130, among other components. When the node transceiver 120 is powered up, the voltage regulator circuitry 130 may raise a “power good” signal that is used by the PLL 128 as a power-on reset.
As noted above, one or more of the slave nodes 102-2 in the system 100 may receive power transmitted over the bus 106 concurrently with data. For power distribution (which is optional, as some of the slave nodes 102-2 may be configured to have exclusively local power provided to them), the master node 102-1 may place a DC bias on the bus link between the master node 102-1 and the slave node 0 (e.g., by connecting, through a low-pass filter, one of the downstream terminals to a voltage source provided by a voltage regulator and the other downstream terminal to ground). The DC bias may be a predetermined voltage, such as 5 volts, 8 volts, the voltage of a car battery, or a higher voltage. Each successive slave node 102-2 can selectively tap its upstream bus link to recover power (e.g., using the voltage regulator circuitry 130). This power may be used to power the slave node 102-2 itself (and optionally one or more peripheral device 108 coupled to the slave node 102-2). A slave node 102-2 may also selectively bias the bus link downstream for the next-in-line slave node 102-2 with either the recovered power from the upstream bus link or from a local power supply. For example, the slave node 0 may use the DC bias on the upstream bus link 106 to recover power for the slave node 0 itself and/or for one or more associated peripheral device 108, and/or the slave node 0 may recover power from its upstream bus link 106 to bias its downstream bus link 106.
Thus, in some embodiments, each node in the system 100 may provide power to the following downstream node over a downstream bus link. The powering of nodes may be performed in a sequenced manner. For example, after discovering and configuring the slave node 0 via the bus 106, the master node 102-1 may instruct the slave node 0 to provide power to its downstream bus link 106 to provide power to the slave node 1; after the slave node 1 is discovered and configured, the master node 102-1 may instruct the slave node 1 to provide power to its downstream bus link 106 to provide power to the slave node 2 (and so on for additional slave nodes 102-2 coupled to the bus 106). In some embodiments, one or more of the slave nodes 102-2 may be locally powered, instead of or in addition to being powered from its upstream bus link. In some such embodiments, the local power source for a given slave node 102-2 may be used to provide power to one or more downstream slave nodes.
In some embodiments, upstream filtering circuitry 132 may be disposed between the upstream DS transceiver 122 and the voltage regulator circuitry 130, and downstream filtering circuitry 131 may be disposed between the downstream DS transceiver 124 and the voltage regulator circuitry 130. Since each link of the bus 106 may carry AC (signal) and DC (power) components, the upstream filtering circuitry 132 and the downstream filtering circuitry 131 may separate the AC and DC components, providing the AC components to the upstream DS transceiver 122 and the downstream DS transceiver 124, and providing the DC components to the voltage regulator circuitry 130. AC couplings on the line side of the upstream DS transceiver 122 and downstream DS transceiver 124 substantially isolate the transceivers 122 and 124 from the DC component on the line to allow for high speed bi-directional communications. As discussed above, the DC component may be tapped for power, and the upstream filtering circuitry 132 and the downstream filtering circuitry 131 may include a ferrite, a common mode choke, or an inductor, for example, to reduce the AC component provided to the voltage regulator circuitry 130. In some embodiments, the upstream filtering circuitry 132 may be included in the upstream DS transceiver 122, and/or the downstream filtering circuitry 131 may be included in the downstream DS transceiver 124; in other embodiments, the filtering circuitry may be external to the transceivers 122 and 124.
The node transceiver 120 may include a transceiver 127 for I2S, TDM, and PDM communication between the node transceiver 120 and an external device 155. Although the “external device 155” may be referred to in the singular herein, this is simply for ease of illustration, and multiple external devices may communicate with the node transceiver 120 via the I2S/TDM/PDM transceiver 127. As known in the art, the I2S protocol is for carrying pulse code modulated (PCM) information (e.g., between audio chips on a PCB). As used herein, “I2S/TDM” may refer to an extension of the I2S stereo (2-channel) content to multiple channels using TDM. As known in the art, PDM may be used in sigma delta converters, and in particular, PDM format may represent an over-sampled 1-bit sigma delta ADC signal before decimation. PDM format is often used as the output format for digital microphones. The I2S/TDM/PDM transceiver 127 may be in communication with the bus protocol circuitry 126 and pins for communication with the external device 155. Six pins, BCLK, SYNC, DTX[1:0], and DRX[1:0], are illustrated in
When the node transceiver 120 is included in the master node 102-1, the external device 155 may include the host 110, and the I2S/TDM/PDM transceiver 127 may provide an I2S slave (regarding BCLK and SYNC) that can receive data from the host 110 and send data to the host 110 synchronously with an I2S interface clock of the host 110. In particular, an I2S frame synchronization signal may be received at the SYNC pin as an input from the host 110, and the PLL 128 may use that signal to generate clocks. When the node transceiver 120 is included in a slave node 102-2, the external device 155 may include one or more peripheral devices 108, and the I2S/TDM/PDM transceiver 127 may provide an I2S clock master (for BCLK and SYNC) that can control I2S communication with the peripheral device 108. In particular, the I2S/TDM/PDM transceiver 127 may provide an I2S frame synchronization signal at the SYNC pin as an output. Registers in the node transceiver 120 may determine which and how many I2S/TDM channels are being transmitted as data slots over the bus 106. A TDM mode (TDM MODE) register in the node transceiver 120 may store a value of how many TDM channels fit between consecutive SYNC pulses on a TDM transmit or receive pin. Together with knowledge of the channel size, the node transceiver 120 may automatically set the BCLK rate to match the number of bits within the sampling time (e.g., 48 kHz).
The node transceiver 120 may include a transceiver 129 for I2C communication between the node transceiver 120 and an external device 157. Although the “external device 157” may be referred to in the singular herein, this is simply for ease of illustration, and multiple external devices may communicate with the node transceiver 120 via the I2C transceiver 129. As known in the art, the I2C protocol uses clock (SCL) and data (SDA) lines to provide data transfer. The I2C transceiver 129 may be in communication with the bus protocol circuitry 126 and pins for communication with the external device 157. Four pins, ADR1, ADR2, SDA, and SCL are illustrated in
The node transceiver 120 may include an interrupt request (IRQ) pin in communication with the bus protocol circuitry 126. When the node transceiver 120 is included in the master node 102-1, the bus protocol circuitry 126 may provide event-driven interrupt requests toward the host 110 via the IRQ pin. When the node transceiver 120 is included in a slave node 102-2 (e.g., when the MSTR pin is low), the IRQ pin may serve as a GPIO pin with interrupt request capability.
The system 100 may operate in any of a number of different operational modes. The nodes on the bus 106 may each have a register indicating which operational mode is currently enabled. Descriptions follow of examples of various operational modes that may be implemented. In a standby operational mode, bus activity is reduced to enable global power savings; the only traffic required is a minimal downstream preamble to keep the Pas of each node (e.g., the PLL 128) synchronized. In standby operational mode, reads and writes across the bus 106 are not supported. In a discovery operational mode, the master node 102-1 may send predetermined signals out along the bus 106 and wait for suitable responses to map out the topology of slave nodes 102-2 distributed along the bus 106. In a normal operational mode, full register access may be available to and from the slave nodes 102-2 as well as access to and from peripheral devices 108 over the bus 106. Normal mode may be globally configured by the host 110 with or without synchronous upstream data and with or without synchronous downstream data.
For example, in some embodiments, communication along the bus 106 may be encoded using a clock first, transition on zero differential Manchester coding scheme. According to such an encoding scheme, each bit time begins with a clock transition. If the data value is zero, the encoded signal transitions again in the middle of the bit time. If the data value is one, the encoded signal does not transition again. The preamble 182 illustrated in
The bus protocol circuitry 126 may include differential Manchester decoder circuitry that runs on a clock recovered from the bus 106 and that detects the synchronization control frame 180 to send a frame sync indicator to the PLL 128. In this manner, the synchronization control frame 180 may be detected without using a system clock or a higher-speed oversampling clock. Consequently, the slave nodes 102-2 can receive a PLL synchronization signal from the bus 106 without requiring a crystal clock source at the slave nodes 102-2.
As noted above, communications along the bus 106 may occur in periodic superframes.
In
The period of upstream transmission 194 may include a synchronization response frame 197 and Y upstream data slots 199, where Y can be zero. In some embodiments, each slave node 102-2 may consume a portion of the downstream data slots 198. The last slave node (e.g., slave node 2 in
As discussed above, the synchronization control frame 180 may begin each downstream transmission. In some embodiments, the synchronization control frame 180 may be 64 bits in length, but any other suitable length may be used. The synchronization control frame 180 may begin with the preamble 182, as noted above. In some embodiments, when the synchronization control frame 180 is retransmitted by a slave node 102-2 to a downstream slave node 102-2, the preamble 182 may be generated by the transmitting slave node 102-2, rather than being retransmitted.
The control data 184 of the synchronization control frame 180 may include fields that contain data used to control transactions over the bus 106. Examples of these fields are discussed below, and some embodiments are illustrated in
In some embodiments, the synchronization control frame 180 may include a count (CNT) field. The CNT field may have any suitable length (e.g., 2 bits) and may be incremented (modulo the length of the field) from the value used in the previous superframe. A slave node 102-2 that receives a CNT value that is unexpected may be programmed to return an interrupt.
In some embodiments, the synchronization control frame 180 may include a node addressing mode (NAM) field. The NAM field may have any suitable length (e.g., 2 bits) and may be used to control access to registers of a slave node 102-2 over the bus 106. In normal mode, registers of a slave node 102-2 may be read from and/or written to based on the ID of the slave node 102-2 and the address of the register. Broadcast transactions are writes which should be taken by every slave node 102-2. In some embodiments, the NAM field may provide for four node addressing modes, including “none” (e.g., data not addressed to any particular slave node 102-2), “normal” (e.g., data unicast to a specific slave node 102-2 specified in the address field discussed below), “broadcast” (e.g., addressed to all slave nodes 102-2), and “discovery.”
In some embodiments, the synchronization control frame 180 may include an I2C field. The I2C field may have any suitable length (e.g., 1 bit) and may be used to indicate that the period of downstream transmission 192 includes an I2C transaction. The I2C field may indicate that the host 110 has provided instructions to remotely access a peripheral device 108 that acts as an I2C slave with respect to an associated slave node 102-2.
In some embodiments, the synchronization control frame 180 may include a node field. The node field may have any suitable length (e.g., 4 bits) and may be used to indicate which slave node is being addressed for normal and I2C accesses. In discovery mode, this field may be used to program an identifier for a newly discovered slave node 102-2 in a node ID register of the slave node 102-2. Each slave node 102-2 in the system 100 may be assigned a unique ID when the slave node 102-2 is discovered by the master node 102-1, as discussed below. In some embodiments, the master node 102-1 does not have a node ID, while in other embodiments, the master node 102-1 may have a node ID. In some embodiments, the slave node 102-2 attached to the master node 102-1 on the bus 106 (e.g., the slave node 0 in
In some embodiments, the synchronization control frame 180 may include a read/write (RW) field. The RW field may have any suitable length (e.g., 1 bit) and may be used to control whether normal accesses are reads (e.g., RW==1) or writes (e.g., RW==0).
In some embodiments, the synchronization control frame 180 may include an address field. The address field may have any suitable length (e.g., 8 bits) and may be used to address specific registers of a slave node 102-2 through the bus 106. For I2C transactions, the address field may be replaced with I2C control values, such as START/STOP, WAIT, RW, and DATA VLD. For discovery transactions, the address field may have a predetermined value (e.g., as illustrated in
In some embodiments, the synchronization control frame 180 may include a data field. The data field may have any suitable length (e.g., 8 bits) and may be used for normal, I2C, and broadcast writes. The RESPCYCS value, multiplied by 4, may be used to determine how many cycles a newly discovered node should allow to elapse between the start of the synchronization control frame 180 being received and the start of the synchronization response frame 197 being transmitted. When the NAM field indicates discovery mode, the node address and data fields discussed below may be encoded as a RESPCYCS value that, when multiplied by a suitable optional multiplier (e.g., 4), indicates the time, in bits, from the end of the synchronization control frame 180 to the start of the synchronization response frame 197. This allows a newly discovered slave node 102-2 to determine the appropriate time slot for upstream transmission.
In some embodiments, the synchronization control frame 180 may include a cyclic redundancy check (CRC) field. The CRC field may have any suitable length (e.g., 16 bits) and may be used to transmit a CRC value for the control data 184 of the synchronization control frame 180 following the preamble 182. In some embodiments, the CRC may be calculated in accordance with the CCITT-CRC error detection scheme.
In some embodiments, at least a portion of the synchronization control frame 180 between the preamble 182 and the CRC field may be scrambled to reduce the likelihood that a sequence of bits in this interval will periodically match the preamble 182 (and thus may be misinterpreted by the slave node 102-2 as the start of a new superframe 190), as well as to reduce electromagnetic emissions as noted above. In some such embodiments, the CNT field of the synchronization control frame 180 may be used by scrambling logic to ensure that the scrambled fields are scrambled differently from one superframe to the next. Various embodiments of the system 100 described herein may omit scrambling.
Other techniques may be used to ensure that the preamble 182 can be uniquely identified by the slave nodes 102-2 or to reduce the likelihood that the preamble 182 shows up elsewhere in the synchronization control frame 180, in addition to or in lieu of techniques such as scrambling and/or error encoding as discussed above. For example, a longer synchronization sequence may be used to reduce the likelihood that a particular encoding of the remainder of the synchronization control frame 180 will match it. Additionally or alternatively, the remainder of the synchronization control frame may be structured so that the synchronization sequence cannot occur, such as by placing fixed “0” or “1” values at appropriate bits.
The master node 102-1 may send read and write requests to the slave nodes 102-2, including both requests specific to communication on the bus 106 and I2C requests. For example, the master node 102-1 may send read and write requests (indicated using the RW field) to one or more designated slave nodes 102-2 (using the NAM and node fields) and can indicate whether the request is a request for the slave node 102-2 specific to the bus 106, an I2C request for the slave node 102-2, or an I2C request to be passed along to an I2C-compatible peripheral device 108 coupled to the slave node 102-2 at one or more I2C ports of the slave node 102-2.
Turning to upstream communication, the synchronization response frame 197 may begin each upstream transmission. In some embodiments, the synchronization response frame 197 may be 64 bits in length, but any other suitable length may be used. The synchronization response frame 197 may also include a preamble, as discussed above with reference to the preamble 182 of the synchronization control frame 180, followed by data portion. At the end of a downstream transmission, the last slave node 102-2 on the bus 106 may wait until the RESPCYCS counter has expired and then begin transmitting a synchronization response frame 197 upstream. If an upstream slave node 102-2 has been targeted by a normal read or write transaction, a slave node 102-2 may generate its own synchronization response frame 197 and replace the one received from downstream. If any slave node 102-2 does not see a synchronization response frame 197 from a downstream slave node 102-2 at the expected time, the slave node 102-2 will generate its own synchronization response frame 197 and begin transmitting it upstream.
The data portion of the synchronization response frame 197 may include fields that contain data used to communicate response information back to the master node 102-1. Examples of these fields are discussed below, and some embodiments are illustrated in
In some embodiments, the synchronization response frame 197 may include a count (CNT) field. The CNT field may have any suitable length (e.g., 2 bits) and may be used to transmit the value of the CNT field in the previously received synchronization control frame 180.
In some embodiments, the synchronization response frame 197 may include an acknowledge (ACK) field. The ACK field may have any suitable length (e.g., 2 bits), and may be inserted by a slave node 102-2 to acknowledge a command received in the previous synchronization control frame 180 when that slave node 102-2 generates the synchronization response frame 197. Example indicators that may be communicated in the ACK field include wait, acknowledge, not acknowledge (NACK), and retry. In some embodiments, the ACK field may be sized to transmit an acknowledgment by a slave node 102-2 that it has received and processed a broadcast message (e.g., by transmitting a broadcast acknowledgment to the master node 102-1). In some such embodiments, a slave node 102-2 also may indicate whether the slave node 102-2 has data to transmit (which could be used, for example, for demand-based upstream transmissions, such as non-TDM inputs from a keypad or touchscreen, or for prioritized upstream transmission, such as when the slave node 102-2 wishes to report an error or emergency condition).
In some embodiments, the synchronization response frame 197 may include an I2C field. The I2C field may have any suitable length (e.g., 1 bit) and may be used to transmit the value of the I2C field in the previously received synchronization control frame 180.
In some embodiments, the synchronization response frame 197 may include a node field. The node field may have any suitable length (e.g., 4 bits) and may be used to transmit the ID of the slave node 102-2 that generates the synchronization response frame 197.
In some embodiments, the synchronization response frame 197 may include a data field. The data field may have any suitable length (e.g., 8 bits), and its value may depend on the type of transaction and the ACK response of the slave node 102-2 that generates the synchronization response frame 197. For discovery transactions, the data field may include the value of the RESPCYCS field in the previously received synchronization control frame 180. When the ACK field indicates a NACK, or when the synchronization response frame 197 is responding to a broadcast transaction, the data field may include a broadcast acknowledge (BA) indicator (in which the last slave node 102-2 may indicate if the broadcast write was received without error), a discovery error (DER) indicator (indicating whether a newly discovered slave node 102-2 in a discovery transaction matches an existing slave node 102-2), and a CRC error (CER) indicator (indicating whether a NACK was caused by a CRC error).
In some embodiments, the synchronization response frame 197 may include a CRC field. The CRC field may have any suitable length (e.g., 16 bits) and may be used to transmit a CRC value for the portion of the synchronization response frame 197 between the preamble and the CRC field.
In some embodiments, the synchronization response frame 197 may include an interrupt request (IRQ) field. The IRQ field may have any suitable length (e.g., 1 bit) and may be used to indicate that an interrupt has been signaled from a slave node 102-2.
In some embodiments, the synchronization response frame 197 may include an IRQ node (IRQNODE) field. The IRQNODE field may have any suitable length (e.g., 4 bits) and may be used to transmit the ID of the slave node 102-2 that has signaled the interrupt presented by the IRQ field. In some embodiments, the slave node 102-2 for generating the IRQ field will insert its own ID into the IRQNODE field.
In some embodiments, the synchronization response frame 197 may include a second CRC (CRC-4) field. The CRC-4 field may have any suitable length (e.g., 4 bits) and may be used to transmit a CRC value for the IRQ and IRQNODE fields.
In some embodiments, the synchronization response frame 197 may include an IRQ field, an IRQNODE field, and a CRC-4 field as the last bits of the synchronization response frame 197 (e.g., the last 10 bits). As discussed above, these interrupt-related fields may have their own CRC protection in the form of CRC-4 (and thus not protected by the preceding CRC field). Any slave node 102-2 that needs to signal an interrupt to the master node 102-1 will insert its interrupt information into these fields. In some embodiments, a slave node 102-2 with an interrupt pending may have higher priority than any slave node 102-2 further downstream that also has an interrupt pending. The last slave node 102-2 along the bus 106 (e.g., the slave node 2 in
In some embodiments, at least a portion of the synchronization response frame 197 between the preamble 182 and the CRC field may be scrambled to reduce emissions. In some such embodiments, the CNT field of the synchronization response frame 197 may be used by scrambling logic to ensure that the scrambled fields are scrambled differently from one superframe to the next. Various embodiments of the system 100 described herein may omit scrambling.
Other techniques may be used to ensure that the preamble 182 can be uniquely identified by the slave nodes 102-2 or to reduce the likelihood that the preamble 182 shows up elsewhere in the synchronization response frame 197, in addition to or in lieu of techniques such as scrambling and/or error encoding as discussed above. For example, a longer synchronization sequence may be used to reduce the likelihood that a particular encoding of the remainder of the synchronization response frame 197 will match it. Additionally or alternatively, the remainder of the synchronization response frame may be structured so that the synchronization sequence cannot occur, such as by placing fixed “0” or “1” values at appropriate bits.
When the node transceiver 120 is preparing data for transmission along the bus 106, preamble circuitry 156 may be configured to generate preambles for synchronization frames for transmission, and to receive preambles from received synchronization frames. In some embodiments, a downstream synchronization control frame preamble may be sent by the master node 102-1 every 1024 bits. As discussed above, one or more slave nodes 102-2 may synchronize to the downstream synchronization control frame preamble and generate local, phase-aligned master clocks from the preamble.
CRC insert circuitry 158 may be configured to generate one or more CRCs for synchronization frames for transmission. Frame/compress circuitry 160 may be configured to take incoming data from the I2S/TDM/PDM transceiver 127 (e.g., from a frame buffer associated with the transceiver 127) and/or the I2C transceiver 129, optionally compress the data, and optionally generate parity check bits or error correction codes (ECC) for the data. A multiplexer (MUX) 162 may multiplex a preamble from the preamble circuitry 156, synchronization frames, and data into a stream for transmission. In some embodiments, the transmit stream may be scrambled by scrambling circuitry 164 before transmission.
For example, in some embodiments, the frame/compress circuitry 160 may apply a floating point compression scheme. In such an embodiment, the control circuitry 154 may transmit 3 bits to indicate how many repeated sign bits are in the number, followed by a sign bit and N-4 bits of data, where N is the size of the data to be transmitted over the bus 106. The use of data compression may be configured by the master node 102-1 when desired.
In some embodiments, the receive stream entering the node transceiver 120 may be descrambled by the descrambling circuitry 166. A demultiplexer (DEMUX) 168 may demultiplex the preamble, synchronization frames, and data from the receive stream. CRC check circuitry 159 on the receive side may check received synchronization frames for the correct CRC. When the CRC check circuitry 159 identifies a CRC failure in an incoming synchronization control frame 180, the control circuitry 154 may be notified of the failure and will not perform any control commands in the control data 184 of the synchronization control frame 180. When the CRC check circuitry 159 identifies a CRC failure in an incoming synchronization response frame 197, the control circuitry 154 may be notified of the failure and may generate an interrupt for transmission to the host 110 in an interrupt frame. Deframe/decompress circuitry 170 may accept receive data, optionally check its parity, optionally perform error detection and correction (e.g., single error correction—double error detection (SECDED)), optionally decompress the data, and may write the receive data to the I2S/TDM/PDM transceiver 127 (e.g., a frame buffer associated with the transceiver 127) and/or the I2C transceiver 129.
As discussed above, upstream and downstream data may be transmitted along the bus 106 in TDM data slots within a superframe 190. The control circuitry 154 may include registers dedicated to managing these data slots on the bus 106, a number of examples of which are discussed below. When the control circuitry 154 is included in a master node 102-1, the values in these registers may be programmed into the control circuitry 154 by the host 110. When the control circuitry 154 is included in a slave node 102-2, the values in these registers may be programmed into the control circuitry 154 by the master node 102-1.
In some embodiments, the control circuitry 154 may include a downstream slots (DNSLOTS) register. When the node transceiver 120 is included in the master node 102-1, this register may hold the value of the total number of downstream data slots. This register may also define the number of data slots that will be used for combined I2S/TDM/PDM receive by the I2S/TDM/PDM transceiver 127 in the master node 102-1. In a slave node 102-2, this register may define the number of data slots that are passed downstream to the next slave node 102-2 before or after the addition of locally generated downstream slots, as discussed in further detail below with reference to LDNSLOTS.
In some embodiments, the control circuitry 154 may include a local downstream slots (LDNSLOTS) register. This register may be unused in the master node 102-1. In a slave node 102-2, this register may define the number of data slots that the slave node 102-2 will use and not retransmit. Alternatively, this register may define the number of slots that the slave node 102-2 may contribute to the downstream bus link 106.
In some embodiments, the control circuitry 154 may include an upstream slots (UPSLOTS) register. In the master node 102-1, this register may hold the value of the total number of upstream data slots. This register may also define the number of slots that will be used for I2S/TDM transmit by the I2S/TDM/PDM transceiver 127 in the master node 102-1. In a slave node 102-2, this register may define the number of data slots that are passed upstream before the slave node 102-2 begins to add its own data.
In some embodiments, the control circuitry 154 may include a local upstream slots (LUPSLOTS) register. This register may be unused in the master node 102-1. In a slave node 102-2, this register may define the number of data slots that the slave node 102-2 will add to the data received from downstream before it is sent upstream. This register may also define the number of data slots that will be used for combined I2S/TDM/PDM receive by the I2S/TDM/PDM transceiver 127 in the slave node 102-2.
In some embodiments, the control circuitry 154 may include a broadcast downstream slots (BCDNSLOTS) register. This register may be unused in the master node 102-1. In a slave node 102-2, this register may define the number of broadcast data slots. In some embodiments, broadcast data slots may always come at the beginning of the data field. The data in the broadcast data slots may be used by multiple slave nodes 102-2 and may be passed downstream by all slave nodes 102-2 whether or not they are used.
In some embodiments, the control circuitry 154 may include a slot format (SLOTFMT) register. This register may define the format of data for upstream and downstream transmissions. The data size for the I2S/TDM/PDM transceiver 127 may also be determined by this register. In some embodiments, valid data sizes include 8, 12, 16, 20, 24, 28, and 32 bits. This register may also include bits to enable floating point compression for downstream and upstream traffic. When floating point compression is enabled, the I2S/TDM data size may be 4 bits larger than the data size over the bus 106. All nodes in the system 100 may have the same values for SLOTFMT when data slots are enabled, and the nodes may be programmed by a broadcast write so that all nodes will be updated with the same value.
To begin,
In
At this point, slave node 7 transmits to slave node 6 the SRF followed by its data (see the row labeled SLAVE 6). Slave node 6 forwards to slave node 5 the SRF along with the data from slave node 7 and its own data, and slave node 5 in turn forwards to slave node 4 the SRF along with the data from slave nodes 7 and 6. Slave node 4 has no data to add, so it simply forwards the data to slave node 3 (see the row labeled SLAVE 3), which forwards the data along with its own data to slave node 2 (see the row labeled SLAVE 2), which in turn forwards the data along with its own data to slave node 1. Slave node 1 has no data to add, so it forwards the data to slave node 0, which forwards the data along with its own data. As a result, the master node 102-1 receives the SRF followed by the data from slave nodes 7, 6, 3, 2, and 0 (see the row labeled MASTER).
As discussed above, each slave node 102-2 may remove data from downstream or upstream transmissions and/or may add data to downstream or upstream transmissions. Thus, for example, the master node 102-1 may transmit a separate sample of data to each of a number of slave nodes 102-2, and each such slave node 102-2 may remove its data sample and forward only data intended for downstream slaves. On the other hand, a slave node 102-2 may receive data from a downstream slave node 102-2 and forward the data along with additional data. One advantage of transmitting as little information as needed is to reduce the amount of power consumed collectively by the system 100.
The system 100 may also support broadcast transmissions (and multicast transmissions) from the master node 102-1 to the slave nodes 102-2, specifically through configuration of the downstream slot usage of the slave nodes 102-2. Each slave node 102-2 may process the broadcast transmission and pass it along to the next slave node 102-2, although a particular slave node 102-2 may “consume” the broadcast message, (i.e., not pass the broadcast transmission along to the next slave node 102-2).
The system 100 may also support upstream transmissions (e.g., from a particular slave node 102-2 to one or more other slave nodes 102-2). Such upstream transmissions can include unicast, multicast, and/or broadcast upstream transmissions. With upstream addressing, as discussed above with reference to downstream transmissions, a slave node 102-2 may determine whether or not to remove data from an upstream transmission and/or whether or not to pass an upstream transmission along to the next upstream slave node 102-2 based on configuration of the upstream slot usage of the slave nodes 102-2. Thus, for example, data may be passed by a particular slave node 102-2 to one or more other slave nodes 102-2 in addition to, or in lieu of, passing the data to the master node 102-1. Such slave-slave relationships may be configured, for example, via the master node 102-1.
Thus, in various embodiments, the slave nodes 102-2 may operate as active/intelligent repeater nodes, with the ability to selectively forward, drop, and add information. The slave nodes 102-2 may generally perform such functions without necessarily decoding/examining all of the data, since each slave node 102-2 knows the relevant time slot(s) within which it will receive/transmit data, and hence can remove data from or add data into a time slot. Notwithstanding that the slave nodes 102-2 may not need to decode/examine all data, the slave nodes 102-2 may typically re-clock the data that it transmits/forwards. This may improve the robustness of the system 100.
In some embodiments, the bus 106 may be configured for unidirectional communications in a ring topology. For example,
As described herein, data may be communicated between elements of the system 100 in any of a number of ways. In some embodiments, data may be sent as part of a set of synchronous data slots upstream (e.g., using the data slots 199) by a slave node 102-2 or downstream (e.g., using the data slots 198) by a slave node 102-2 or a master node 102-1. The volume of such data may be adjusted by changing the number of bits in a data slot, or including extra data slots. Data may also be communicated in the system 100 by inclusion in a synchronization control frame 180 or a synchronization response frame 197. Data communicated this way may include I2C control data from the host 110 (with a response from a peripheral device 108 associated with a slave node 102-2); accesses to registers of the slave nodes 102-2 (e.g., for discovery and configuration of slots and interfaces) that may include write access from the host 110/master node 102-1 to a slave node 102-2 and read access from a slave node 102-2 to the host 110/master node 102-1; and event signaling via interrupts from a peripheral device 108 to the host 110. In some embodiments, GPIO pins may be used to convey information from a slave node 102-2 to the master node 102-1 (e.g., by having the master node 102-1 poll the GPIO pins over I2C, or by having a node transceiver 120 of a slave node 102-2 generate an interrupt at an interrupt request pin). For example, in some such embodiments, a host 110 may send information to the master node 102-1 via I2C, and then the master node 102-1 may send that information to the slave via the GPIO pins. Any of the types of data discussed herein as transmitted over the bus 106 may be transmitted using any one or more of these communication pathways. Other types of data and data communication techniques within the system 100 may be disclosed herein.
Embodiments of the present disclosure may be implemented into a system using any suitable hardware and/or software to configure as desired.
Additionally, in various embodiments, the device 1300 may not include one or more of the components illustrated in
The device 1300 may include the node transceiver 120, in accordance with any of the embodiments disclosed herein, for managing communication along the bus 106 when the device 1300 is coupled to the bus 106. The device 1300 may include a processing device 1302 (e.g., one or more processing devices), which may be included in the node transceiver 120 or separate from the node transceiver 120. As used herein, the term “processing device” may refer to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that may be stored in registers and/or memory. The processing device 1302 may include one or more DSPs, ASICs, central processing units (CPUs), graphics processing units (GPUs), cryptoprocessors, or any other suitable processing devices. The device 1300 may include a memory 1304, which may itself include one or more memory devices such as volatile memory (e.g., dynamic random access memory (DRAM)), non-volatile memory (e.g., read-only memory (ROM)), flash memory, solid state memory, and/or a hard drive.
In some embodiments, the memory 1304 may be employed to store a working copy and a permanent copy of programming instructions to cause the device 1300 to perform any suitable ones of the techniques disclosed herein. In some embodiments, machine-accessible media (including non-transitory computer-readable storage media), methods, systems, and devices for performing the above-described techniques are illustrative examples of embodiments disclosed herein for communication over a two-wire bus. For example, a computer-readable media (e.g., the memory 1304) may have stored thereon instructions that, when executed by one or more of the processing devices included in the processing device 1302, cause the device 1300 to perform any of the techniques disclosed herein.
In some embodiments, the device 1300 may include another communication chip 1312 (e.g., one or more other communication chips). For example, the communication chip 1312 may be configured for managing wireless communications for the transfer of data to and from the device 1300. The term “wireless” and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments they might not.
The communication chip 1312 may implement any of a number of wireless standards or protocols, including but not limited to Institute for Electrical and Electronic Engineers (IEEE) standards including Wi-Fi (IEEE 802.11 family), IEEE 802.16 standards (e.g., IEEE 802.16-2005 Amendment), Long-Term Evolution (LTE) project along with any amendments, updates, and/or revisions (e.g., advanced LTE project, ultra mobile broadband (UMB) project (also referred to as “3GPP2”), etc.). IEEE 802.16 compatible Broadband Wireless Access (BWA) networks are generally referred to as WiMAX networks, an acronym that stands for Worldwide Interoperability for Microwave Access, which is a certification mark for products that pass conformity and interoperability tests for the IEEE 802.16 standards. The one or more communication chips 1312 may operate in accordance with a Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Evolved HSPA (E-HSPA), or LTE network. The one or more communication chips 1312 may operate in accordance with Enhanced Data for GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). The one or more communication chips 1312 may operate in accordance with Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Telecommunications (DECT), Evolution-Data Optimized (EV-DO), and derivatives thereof, as well as any other wireless protocols that are designated as 3G, 4G, 5G, and beyond. The communication chip 1312 may operate in accordance with other wireless protocols in other embodiments. The device 1300 may include an antenna 1322 to facilitate wireless communications and/or to receive other wireless communications (such as AM or FM radio transmissions).
In some embodiments, the communication chip 1312 may manage wired communications using a protocol other than the protocol for the bus 106 described herein. Wired communications may include electrical, optical, or any other suitable communication protocols. Examples of wired communication protocols that may be enabled by the communication chip 1312 include Ethernet, Controller Area Network (CAN), I2C, Media Oriented Systems Transport (MOST), or any other suitable wired communication protocol.
As noted above, the communication chip 1312 may include multiple communication chips. For instance, a first communication chip 1312 may be dedicated to shorter-range wireless communications such as Wi-Fi or Bluetooth, and a second communication chip 1312 may be dedicated to longer-range wireless communications such as Global Positioning System (GPS), EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, or others. In some embodiments, a first communication chip 1312 may be dedicated to wireless communications, and a second communication chip 1312 may be dedicated to wired communications.
The device 1300 may include battery/power circuitry 1314. The battery/power circuitry 1314 may include one or more energy storage devices (e.g., batteries or capacitors) and/or circuitry for coupling components of the device 1300 to an energy source separate from the device 1300 (e.g., AC line power, voltage provided by a car battery, etc.). For example, the battery/power circuitry 1314 may include the upstream filtering circuitry 132 and the downstream filtering circuitry 131 discussed above with reference to
The device 1300 may include a display device 1306 (or corresponding interface circuitry, as discussed above). The display device 1306 may include any visual indicators, such as a heads-up display, a computer monitor, a projector, a touchscreen display, a liquid crystal display (LCD), a light-emitting diode display, or a flat panel display, for example.
The device 1300 may include an audio output device 1308 (or corresponding interface circuitry, as discussed above). The audio output device 1308 may include any device that generates an audible indicator, such as speakers, headsets, or earbuds, for example.
The device 1300 may include an audio input device 1324 (or corresponding interface circuitry, as discussed above). The audio input device 1324 may include any device that generates a signal representative of a sound, such as microphones, microphone arrays, or digital instruments (e.g., instruments having a musical instrument digital interface (MIDI) output).
The device 1300 may include a GPS device 1318 (or corresponding interface circuitry, as discussed above). The GPS device 1318 may be in communication with a satellite-based system and may receive a location of the device 1300, as known in the art.
The device 1300 may include another output device 1310 (or corresponding interface circuitry, as discussed above). Examples of the other output device 1310 may include an audio codec, a video codec, a printer, a wired or wireless transmitter for providing information to other devices, or an additional storage device. Additionally, any suitable ones of the peripheral devices 108 discussed herein may be included in the other output device 1310.
The device 1300 may include another input device 1320 (or corresponding interface circuitry, as discussed above). Examples of the other input device 1320 may include an accelerometer, a gyroscope, an image capture device, a keyboard, a cursor control device such as a mouse, a stylus, a touchpad, a bar code reader, a Quick Response (QR) code reader, or a radio frequency identification (RFID) reader. Additionally, any suitable ones of the sensors or peripheral devices 108 discussed herein may be included in the other input device 1320.
Any suitable ones of the display, input, output, communication, or memory devices described above with reference to the device 1300 may serve as the peripheral device 108 in the system 100. Alternatively or additionally, suitable ones of the display, input, output, communication, or memory devices described above with reference to the device 1300 may be included in a host (e.g., the host 110) or a node (e.g., a master node 102-1 or a slave node 102-2).
In some embodiments, a master node 102-1 and a slave node 102-2 may each include receive and transmit mailboxes for communication therebetween. Some embodiments may use I2C for the mailbox communication; the I2C interface of a node 102 (e.g., managed by the I2C transceiver 129) may be configured as an I2C slave so that a processing device can program the node 102 over I2C and initiate reads and/or writes to the mailboxes.
In some embodiments, the node transceiver 120 for a slave node 102-2 may include receive and transmit registers that can be used as input and output “mailboxes” for communication between a processing device 1302 of the master node 102-1 and a processing device 1302 of the slave node 102-2 (e.g., a processing device separate from the node transceiver 120), or between a processing device 1302 of another slave node 102-2 and a processing device 1302 of the slave node 102-2. For clarify of illustration, the embodiment in which mailboxes are used to communicate between a master node 102-1 and a slave node 102-2 is discussed below, but the same operations may be performed for mailbox communication between slave nodes 102-2. The master node 102-1 and the slave node 102-2 may be notified of data in their respective mailboxes by an interrupt triggered upon completion of data writing to the mailbox. The node transceiver 120 of a node 102 may be configured to generate an interrupt to a processing device 1302 included in the node 102 upon completion of data writing to a relevant mailbox.
A node transceiver 120 may include a number of registers for control of these mailboxes. In some embodiments, MBOX0CTL and MBOX1CTL registers may provide fields to enable these mailboxes and to control direction, message length, and interrupt enables for the mailboxes.
Mailbox 0 may be configured as a receive mailbox (e.g., the receive mailbox 2710, written by the master node 102-1 and read by a processing device 1302 of the slave node 102-2) by default. Mailbox 1 may be configured as a transmit mailbox (e.g., the transmit mailbox 2712, written by a processing device 1302 of the slave node 102-2 and read by the master node 102-1) by default.
An MBxLEN field of the MBOXxCTL register may define the length of the associated mailbox. If this field is 0, MBOXxB0 may be the final byte of the mailbox. If this field is 1, MBOXxB1 may be the final byte of the mailbox. If this field is 2, MBOXxB2 may be the final byte of the mailbox. If this field is 3, MBOXxB3 may be the final byte of the mailbox.
For an enabled receive mailbox, if an MBxFIEN bit of the MBOXxCTL register is set, an interrupt to the processing device 1302 of the slave node 102-2 may occur after the final byte of the associated mailbox is written by the master node 102-1 and the node transceiver 120 determines that a bus retry was not necessary. If an MBxEIEN field of the MBOXxCTL register is set, an interrupt to the master node 102-1 may occur after the final byte of the associated mailbox is read by the processing device 1302 of the slave node 102-2.
For an enabled transmit mailbox, if the MBxFIEN field is set, an interrupt to the master node 102-1 may occur after the final byte of the associated mailbox is written by the processing device 1302 of the slave node 102-2. If the MBxEIEN failed is set, an interrupt to the processing device 1302 of the slave node 102-2 may occur after the final byte of the associated mailbox is read by the master node 102-1 and the node transceiver 120 determines that a bus retry was not necessary.
In some embodiments, MBOX0STAT and MBOX1STAT registers may provide status information for the mailboxes. When a mailbox is filled, an associated MBxFULL bit of the MBOXxSTAT register may go high and the MBxEMPTY bit may go low. When a mailbox is emptied, an associated MBxEMPTY bit of the MBOXxSTAT register may go high and the MBxFULL bit may go low. MBxEIRQ and MBxFIRQ bits included in the MBOXxSTAT register may go high when the associated mailbox signals an interrupt to the master node 102-1 or local processor (e.g., the processing device 1302 of the slave node 102-2), and may go low when the interrupt is processed by the master node 102-1 or local processor.
In some embodiments, MBOX0Bn and MBOX1Bn registers may contain mailbox data. Each mailbox may hold up to 32 bits of data in some examples. An MBxLEN field in the MBOXxBn register may define the number of active bytes in the mailbox. In some embodiments, each mailbox may support 8-, 16-, 24-, or 32-bit messages.
As noted above, disclosed herein are systems and techniques for sending content protected digital data (e.g., digital audio) over synchronous, continuous, data networks (e.g., two-wire, daisy-chained master/slave communication networks like the systems 100 disclosed herein). As used herein, a “content protection” technique or system is designed to prevent or limit unauthorized access to and/or reproduction of media content (e.g., software, films, music, books, etc.). Synchronous communication networks may be contrasted with asynchronous communication networks, such as conventional packet-based communication networks. Some embodiments of this technology involve sending synchronous data (e.g., audio and/or video) over a synchronous communication network (e.g., any of the systems 100 disclosed herein) along with required link synchronization information for seamless data encryption and decryption between transmitter and receiver. Techniques for link synchronization over asynchronous data networks exist, but establishing such link synchronization over SDNs presents new challenges. The SDNs disclosed herein may support high-definition audio, for example, allowing Blu-ray, Video on Demand (VOD) services, and other high-definition (HD) audio and video to be transmitted securely over the SDN.
The systems and techniques disclosed herein may support any suitable digital transmission specifications, such as any suitable content protection specifications available from Digital Content Protection LLC (DCP) or the Digital Transmission Licensing Authority (DTLA) (e.g., High-Bandwidth Digital Content Protection (HDCP), Digital Transmission Content Protection (DTCP), etc.). These specifications may provide standards for preventing or limiting the copying of digital video and audio content as it travels across networks or other connected sets of devices (e.g., using a High-Definition Multimedia Interface (HDMI) protocol, a Digital Visual Interface (DVI) protocol, a MOST protocol, a Mobile High-Definition Link (MHL) protocol, a Digital Video (DV) protocol, or a Gigabit Video Interface (GVIF) protocol). To enable infotainment systems (e.g., in vehicles) to support more HD media content and/or content sourced from protected devices like mobile phones, Blu-ray players, and/or online on-demand sources, the systems and techniques disclosed herein may provide protected interfaces that connect different media nodes (e.g., a master node 102-1 and one or more slave nodes 102-2) in a vehicle or other setting (for audio and/or video). For example, a system 100 implementing any of the content protection techniques disclosed herein may prevent or limit the unauthorized reproduction of video content in storage and while transferring the video content from one device to another (for example, from a media player to a television or other display, or from a head unit of a vehicle to a main amplifier of the vehicle).
The CP-SDN transmitter 202, CP-SDN repeater 204, and CP-SDN receiver 206 include cryptographic logic 220 (e.g., including stored programming instructions for execution by a processing device), as known in the art, to perform required encryption and/or decryption of the CP content. The node transceivers 120 in the CP-SDN transmitter 202, CP-SDN repeater 204, and CP-SDN receiver 206 may communicate with the cryptographic logic 220 to provide CP content to the cryptographic logic 220 (transmitted to the node transceiver 120 over the bus 106) and/or receive CP content from the cryptographic logic 220 (for transmission over the bus 106). The other slave nodes 102-2 in the system 200 may act simply as relays, receiving CP content and passing it along the bus 106 to the next slave node 102-2.
A system 200 may also include transmitters (“sources”), repeaters, and/or receivers (“sinks”) of CP data that receive and/or transmit this data via interfaces other than the bus 106 (e.g., via HDMI cables or wirelessly); such devices are not shown in
As noted above, in some embodiments, a system 200 supporting HDCP may be used to provide a direct point-to-point connection between the output of a protected data source (received at a CP-SDN transmitter 202) and a data sink (coupled to the CP-SDN receiver 206). Such SDNs may be used to enable HDMI interfaces between nodes 102 of a system 100, which may require HDCP protection. When the system 100 supports HDCP in accordance with the embodiments disclosed herein, integration of HDMI devices as peripheral devices 108 in the system 100 may be readily achieved. Such systems 100 may be utilized in an infotainment system in a vehicle, for example. Devices that support HDCP (e.g., a master node 102-1 or a slave node 102-2) may be limited by the HDCP license to not allow for copying of the HDCP content, to not permit sending digital content over non-HDCP links, and to not allow HDCP keys to be accessible from outside the device.
In a system 200 that supports HDCP, the DCP specification may serve to define HDCP operation for many commonly used media links, including HDMI, DVI, MHL, WirelessHD, DisplayPort, Universal Serial Bus (USB), and others. DCP may also define an Interface Independent Adaptation (IIA) for any interface choosing to adopt and license DCP under the appropriate agreement. In particular, a system 200 may implement the IIA standard over the software stack supporting communication along the bus 106.
A CP-SDN transmitter 202 and a CP-SDN receiver 206 may utilize multiple cryptographic algorithms, including Advanced Encryption Standard 128 (AES-128), Rivest-Shamir-Adleman (RSA), Elliptic Curve Cryptography (ECC), M6, Hash-based Message Authentication Codes (HMAC), a Pseudo-Random Number Generator (PRNG), and hash functions. These algorithms may be verified against the test vectors is supplied in the HDCP specification. In particular, a processing device 1302 of a CP-SDN transmitter 202 or a CP-SDN receiver 206 may implement all of the required cryptographic algorithms in software, and in some embodiments, may have access to hardware cryptographic engines.
In a system 100 supporting HDCP, the CP-SDN transmitter 202 may verify the authenticity of the CP-SDN receiver 206, and then may send encrypted content meant to be decrypted only by the authenticated CP-SDN receiver 206.
Upon successful completion of the AKE, HDCP encryption may be enabled in the CP-SDN transmitter 202, and the CP-SDN transmitter 202 may begin to transmit protected content to the CP-SDN receiver 206 (1604 and 1614 of
To maintain link synchronization between the CP-SDN transmitter 202 and the CP-SDN receiver 206, the CP-SDN transmitter 202 may periodically include link synchronization parameters in a synchronous slot as a stream header (1606 and 1616 of
When HDCP data is to be transmitted over the bus 106, the cipher used for data encryption may take the form defined by the HDCP specification. When the data is synchronous data (e.g., audio), the byte order in which encryption takes place may begin with the cipher considering the most significant byte of the first sample in the first channel until the least significant byte is reached. The cipher may then advance from the first sample through to the sixteenth sample of the data block (e.g., frame sequence number 0x0 to 0xF). The cipher may then advance in a similar fashion until the last channel of the stream is reached. For example, if a stream of 5. 1 channel, 24-bit audio is to be transmitted, the encryption may start with the most significant byte of the first sample in the first channel, continue in a similar fashion until the sixteenth sample, then move forward with the second channel and so on until the sixth channel is reached. Such an approach may ensure that synchronous CP data, such as audio, continues to be transmitted synchronously across the bus 106. The additional control slot may synchronize the transmitter and receiver, as discussed herein. Authentication protocol messages may take the form defined in the HDCP specification, although in some embodiments, the messages RepeaterAuth_Stream_Manage and RepeaterAuth_Stream_Ready may not be implemented as content stream management may not be applicable.
For robust communication, bit errors in the encrypted data communicated in a system 100 should be detected and corrected. If such bit errors are ignored, decryption may result in noise samples in the output (e.g., 16 noise samples in an audio output corresponding to a set of 16 frames). Communication errors may be indicated in an I2S/TDM error data channel (via the I2S/TDM/PDM transceiver 127 of the node transceiver 120) following the content data channels. Simply repeating the last good known sample in the event of a bit error may not be adequate for HDCP, as the integrity of the data in the set of frames (e.g., 16 samples) is lost and cannot be decrypted. Error handling schemes that include re-requesting a packet (implemented as a data link layer) may not be feasible or desirable for synchronous applications (e.g., audio transfer) and may lead to severe delay. Instead, upon detection of a bit error in the encrypted audio data, the CP-SDN receiver 206 may identify the air and may repeat the last set of decrypted samples as a decryption output so as to permit continuous playback of content (e.g., video or audio). In some embodiments, detection of a bit error may trigger a request for reauthentication, as discussed above with reference to
CP data may be received at a node transceiver 120 via by the I2S/TDM/PDM transceiver 127 (
When the node transceiver 120 is to receive or transmit CP data via the bus 106, the slot size may be configurable in registers of the node transceiver 120. The AKE, link synchronization, and link integrity techniques discussed above may occupy the MSBs of the slot. When the slot is a downstream slot, the remainder of the bits may be 0 when the slot size is greater than 16 bits (for HDCP) or greater than 24 bits (for DTCP). When the slot is an upstream slot, the remainder of the bits may be 0 when the slot size is greater than eight bits.
DTCP user information may be transmitted securely from a node transceiver 120 along the bus 106 in the link synchronization channel. The information may start as soon as a content key is exchanged between the CP-SDN transmitter 202 and the CP-SDN receiver 206. A user at the transmit and may write the CI+ URI information using the registers DTCP_USER_INFO1 through DTCP_USER_INFO8 of the transmit port map. One such writing is complete, the bit TSPORT_CTL2.DTCP_APPLY may be asserted, and afterwards, the updated CI+ URI information is encrypted using the current content key and transmitted securely to the CP-SDN receiver 206. As noted above, an “UpdateDTCPInfo” bit may be toggled in the link synchronization to indicate to the CP-SDN receiver 206 that the CI+ URI information has changed. The new settings may be read using the registers DTCP_USER_INFO1 through DTCP_USER_INFO8 of the receive port map, and then applied.
When implementing HDCP, a system 200 may perform locality checks in accordance with the HDCP specification. In some embodiments, a system 200 may always perform locality checks in which pre-compute is enabled. In some embodiments, a system 200 may not re-attempt locality checks without repeating AKE.
As noted above with reference to
The following paragraphs provide examples of various ones of the embodiments disclosed herein.
Example 1 is a device capable of providing digital content protection to data communicated from the device over a synchronous communication system, including: a transceiver to couple to a link of a two-wire bus of a synchronous communication system; and content protection circuitry to provide content protected data to the transceiver, wherein the transceiver is to transmit the content protected data synchronously over the link of the two-wire bus.
Example 2 includes the subject matter of Example 1, and further specifies that the transceiver is a first transceiver, the link is a first link, and the device further includes: a second transceiver to couple to a second link of a two-wire bus of a synchronous communication system.
Example 3 includes the subject matter of Example 2, and further specifies that the content protected data is first content protected data, the content protection circuitry is to provide second content protected data to the second transceiver, and the second transceiver is to transmit the second content protected data synchronously over the second link of the two-wire bus.
Example 4 includes the subject matter of Example 2, and further specifies that the content protected data is first content protected data, the content protection circuitry is to receive second content protected data from the second transceiver, and the second transceiver is to receive the second content protected data synchronously over the second link of the two-wire bus.
Example 5 includes the subject matter of Example 2, and further specifies that the first transceiver is an upstream transceiver, the first link is an upstream link, the second transceiver is an downstream transceiver, and the second link is a downstream link.
Example 6 includes the subject matter of Example 2, and further specifies that the device is a slave device of the synchronous communication system.
Example 7 includes the subject matter of Example 1, and further specifies that the device is a master device of the synchronous communication system.
Example 8 includes the subject matter of Example 7, and further specifies that the transceiver is a downstream transceiver and the link is a downstream link.
Example 9 includes the subject matter of Example 1, and further specifies that: the content protected data is first content protected data; the content protection circuitry to receive second content protected data from the transceiver; and the transceiver is to receive the second content protected data synchronously over the link of the two-wire bus.
Example 10 includes the subject matter of Example 9, and further includes: a peripheral device interface to couple to a peripheral device, wherein the content protection circuitry is to decrypt the second content protected data, and the peripheral device interface is to transmit the decrypted second content protected data to the peripheral device.
Example 11 includes the subject matter of Example 9, and further specifies that the transceiver is an upstream transceiver.
Example 12 includes the subject matter of Example 9, and further specifies that the transceiver is a downstream transceiver.
Example 13 includes the subject matter of Example 9, and further specifies that the device is a slave device of the synchronous communication system.
Example 14 includes the subject matter of Example 9, and further specifies that the device is a master device of the synchronous communication system.
Example 15 includes the subject matter of Example 1, and further specifies that the content protection circuitry is to decrypt the content protected data.
Example 16 includes the subject matter of Example 1, and further specifies that the content protection circuitry is to encrypt data to generate the content protected data.
Example 17 includes the subject matter of Example 1, and further specifies that the content protected data is protected in accordance with the High-Bandwidth Digital Content Protection (HDCP) specification or the Digital Transmission Content Protection (DTCP) specification.
Example 18 includes the subject matter of Example 1, and further specifies that data transmitted over the two-wire bus is Manchester encoded.
Example 19 includes the subject matter of Example 1, and further specifies that the device is to operate on power received over the two-wire bus.
Example 20 includes the subject matter of Example 1, and further specifies that the device is included in a trunk amplifier for a vehicle.
Example 21 includes the subject matter of Example 1, and further specifies that the device is included in a rear seat entertainment unit for a vehicle.
Example 22 includes the subject matter of Example 1, and further specifies that the device is included in a head unit of a vehicle.
Example 23 includes the subject matter of Example 1, and further specifies that the transceiver is included in a first die, and the content protection circuitry is included in a second die different from the first die.
Example 24 includes the subject matter of Example 23, and further specifies that the first die and the second die are included in a multi-chip package.
Example 25 includes the subject matter of Example 1, and further specifies that the transceiver is to transmit link synchronization information over the two-wire bus in a frame of data.
Example 26 includes the subject matter of Example 1, and further specifies that the transceiver is to transmit the content protected data over the two-wire bus in blocks of 16 frames.
Example 27 includes the subject matter of Example 1, and further includes: a host device interface to couple to a host device, wherein the host device interface is to receive data from the host device, and the content protection circuitry is to encrypt data received from the host device to generate content protected data.
Example 28. A device for use in a content protection synchronous communication system, including: a transceiver to couple to a link of a two-wire bus of a synchronous communication system, wherein the transceiver is to receive content protected data synchronously over the link of the two-wire bus; and content protection circuitry to receive content protected data from the transceiver.
Example 29 includes the subject matter of Example 28, and further specifies that the transceiver is a first transceiver, the link is a first link, and the device further includes: a second transceiver to couple to a second link of a two-wire bus of a synchronous communication system.
Example 30 includes the subject matter of Example 29, and further specifies that the content protected data is first content protected data, the second transceiver is to receive second content protected data synchronously over the second link of the two-wire bus, and the content protection circuitry is to receive the second content protected data from the second transceiver.
Example 31 includes the subject matter of Example 29, and further specifies that the content protected data is first content protected data, the content protection circuitry is to provide second content protected data to the second transceiver, and the second transceiver is to transmit the second content protected data synchronously over the second link of the two-wire bus.
Example 32 includes the subject matter of Example 29, and further specifies that the first transceiver is an upstream transceiver, the first link is an upstream link, the second transceiver is an downstream transceiver, and the second link is a downstream link.
Example 33 includes the subject matter of Example 29, and further specifies that the device is a slave device of the synchronous communication system.
Example 34 includes the subject matter of Example 28, and further specifies that the device is a master device of the synchronous communication system.
Example 35 includes the subject matter of Example 34, and further specifies that the transceiver is a downstream transceiver and the link is a downstream link.
Example 36 includes the subject matter of Example 28, and further specifies that: the content protected data is first content protected data; the content protection circuitry to provide second content protected data to the transceiver; and the transceiver is to transmit the second content protected data synchronously over the link of the two-wire bus.
Example 37 includes the subject matter of Example 36, and further specifies that the transceiver is an upstream transceiver.
Example 38 includes the subject matter of Example 36, and further specifies that the transceiver is a downstream transceiver.
Example 39 includes the subject matter of Example 36, and further specifies that the device is a slave device of the synchronous communication system.
Example 40 includes the subject matter of Example 36, and further specifies that the device is a master device of the synchronous communication system.
Example 41 includes the subject matter of Example 28, and further specifies that the content protection circuitry is to decrypt the content protected data.
Example 42 includes the subject matter of Example 28, and further specifies that the content protection circuitry is to encrypt data to generate the content protected data.
Example 43 includes the subject matter of Example 28, and further specifies that the content protected data is protected in accordance with the High-Bandwidth Digital Content Protection (HDCP) specification or the Digital Transmission Content Protection (DTCP) specification.
Example 44 includes the subject matter of Example 28, and further specifies that data transmitted over the two-wire bus is Manchester encoded.
Example 45 includes the subject matter of Example 28, and further specifies that the device is to operate on power received over the two-wire bus.
Example 46 includes the subject matter of Example 28, and further specifies that the device is included in a trunk amplifier for a vehicle.
Example 47 includes the subject matter of Example 28, and further specifies that the device is included in a rear seat entertainment unit for a vehicle.
Example 48 includes the subject matter of Example 28, and further specifies that the device is included in a head unit of a vehicle.
Example 49 includes the subject matter of Example 28, and further specifies that the transceiver is included in a first die, and the content protection circuitry is included in a second die different from the first die.
Example 50 includes the subject matter of Example 49, and further specifies that the first die and the second die are included in a multi-chip package.
Example 51 includes the subject matter of Example 28, and further specifies that the transceiver is to transmit link synchronization information over the two-wire bus in a frame of data.
Example 52 includes the subject matter of Example 28, and further specifies that the transceiver is to transmit the content protected data over the two-wire bus in blocks of 16 frames.
Example 53. A method of communicating content protected data, including: providing link synchronization information over a link of a synchronous bus; and providing content protected data over the link of the synchronous bus.
Example 54 includes the subject matter of Example 53, and further includes: before providing content protected data over the link of the synchronous bus, performing an authentication and key exchange with a receiving device.
Example 55 includes the subject matter of Example 53, and further specifies that the synchronous bus is a two-wire bus.
Example 56 includes the subject matter of Example 53, and further specifies that the content protected data is protected in accordance with the High-Bandwidth Digital Content Protection (HDCP) specification or the Digital Transmission Content Protection (DTCP) specification.
Example 57 includes the subject matter of Example 53, and further includes: receiving content protected data over the link of the synchronous bus.
Example 58 is a slave device capable of providing digital content protection to data communicated from the slave device over a synchronous communication system, including an upstream transceiver to couple to an upstream link of a two-wire bus of a synchronous communication system, and content protection circuitry to provide content protected data to the upstream transceiver, wherein the upstream transceiver is to transmit the content protected data synchronously over the upstream link of the two-wire bus.
Example 59 includes the subject matter of Example 58, and further specifies that the upstream transceiver is to receive content protected data synchronously over the upstream link of the two-wire bus.
Example 60 includes the subject matter of Example 59, and further specifies that the content protection circuitry is to decrypt the received content protected data.
Example 61 includes the subject matter of any of Examples 58-60, and further includes a downstream transceiver to couple to a downstream link of the two-wire bus of the synchronous communication system, wherein the content protection circuitry is to provide content protected data to the downstream transceiver, and the downstream transceiver is to transmit the content protected data synchronously over the downstream link of the two-wire bus.
Example 62 includes the subject matter of Example 61, and further specifies that the downstream transceiver is to receive content protected data synchronously over the downstream link of the bus.
Example 63 includes the subject matter of any of Examples 58-62, and further specifies that data transmitted over the two-wire bus is Manchester encoded.
Example 64 includes the subject matter of any of Examples 58-63, and further includes a peripheral device interface to couple to a peripheral device, wherein the content protection circuitry is to decrypt content protected data received at the slave device, and the peripheral device interface is to transmit the decrypted content protected data to the peripheral device.
Example 65 includes the subject matter of any of Examples 58-64, and further specifies that the slave node is to operate on power received over the bus.
Example 66 includes the subject matter of any of Examples 58-65, and further specifies that the slave device is included in a trunk amplifier for a vehicle.
Example 67 includes the subject matter of any of Examples 58-66, and further specifies that the slave device is included in a rear seat entertainment unit for a vehicle.
Example 68 is a master device capable of providing digital content protection to data communicated from the slave device over a synchronous communication system, including a downstream transceiver to couple to a downstream link of a two-wire bus of a synchronous communication system, and content protection circuitry to provide content protected data to the downstream transceiver, wherein the downstream transceiver is to transmit the content protected data synchronously over the downstream link of the two-wire bus.
Example 69 includes the subject matter of Example 68, and further specifies that the downstream transceiver is to receive content protected data synchronously over the downstream link of the two-wire bus.
Example 70 includes the subject matter of Example 69, and further specifies that the content protection circuitry is to decrypt the received content protected data.
Example 71 includes the subject matter of any of Examples 68-70, and further specifies that data transmitted over the two-wire bus is Manchester encoded.
Example 72 includes the subject matter of any of Examples 68-71, and further includes a host device interface to couple to a host device, wherein the host device interface is to transmit data to and/or from the host device, and the content protection circuitry is to encrypt data received from the host device to form content protected data.
Example 73 includes the subject matter of any of Examples 68-72, and further specifies that the master node is to provide power over the bus.
Example 74 includes the subject matter of any of Examples 68-73, and further specifies that the master node is included in a head unit for a vehicle.
Example 75 includes the subject matter of any of Examples 58-74, wherein the upstream or downstream transceiver is included in a first die, and the content protection circuitry is included in a second die different from the first die.
Example 76 includes the subject matter of Example 75, and further specifies that the first die and the second die are included in a multi-chip package.
Example 77 includes the subject matter of any of Examples 58-76, and further specifies that link synchronization information is transmitted over the two-wire bus in a frame of data.
Example 78 includes the subject matter of any of Examples 58-77, and further specifies that content protected data is transmitted over the two-wire bus in blocks of 16 frames.
Example 79 is a communication system with content protection functionality, including a master device in accordance with any suitable ones of the preceding Examples, a slave device in accordance with any suitable ones of the preceding Examples, and a two-wire bus link communicatively coupling the master device and the slave device.
Example 80 is a communication system with content protection functionality, in accordance with any of the embodiments disclosed herein.
Example 81 is a method of performing content protection in a synchronous communication system, in accordance with any of the embodiments disclosed herein.
Example 82 is a slave device including means for performing any of the content protection methods disclosed herein.
Example 83 is a master device including means for performing any of the content protection methods disclosed herein.
Example 84 includes any of the elements, or combination of elements, of the data pipes disclosed herein.
Example 85 includes the method of operation of any of the data pipes disclosed herein.
This application claims priority to U.S. Provisional Patent Application No. 62/752,028, filed on Oct. 29, 2018 and titled “CONTENT PROTECTION OVER SYNCHRONOUS DATA NETWORKS,” and also claims priority to U.S. Provisional Patent Application No. 62/843,888, filed on May 6, 2019 and titled “CONTENT PROTECTION OVER SYNCHRONOUS DATA NETWORKS.” Both of these priority applications are incorporated by reference herein in their entireties.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5819051 | Murray et al. | Oct 1998 | A |
| 7158596 | Knapp et al. | Jan 2007 | B2 |
| 7272202 | Knapp et al. | Sep 2007 | B2 |
| 7315551 | Olson et al. | Jan 2008 | B2 |
| 7395362 | Drexler et al. | Jul 2008 | B2 |
| 7539804 | Miura | May 2009 | B2 |
| 7613300 | Kobayashi | Nov 2009 | B2 |
| 7685449 | Terasawa | Mar 2010 | B2 |
| 7707437 | Berenbaum et al. | Apr 2010 | B2 |
| 7802036 | Takeuchi | Sep 2010 | B2 |
| 7966379 | Berenbaum et al. | Jun 2011 | B2 |
| 8147338 | Hutchison-Kay | Apr 2012 | B2 |
| 8156274 | Kapelner | Apr 2012 | B2 |
| 8185759 | Li et al. | May 2012 | B1 |
| 8600583 | Fervel et al. | Dec 2013 | B2 |
| 8615091 | Terwal | Dec 2013 | B2 |
| 8667194 | Dybsetter et al. | Mar 2014 | B2 |
| 8745305 | Toba et al. | Jun 2014 | B2 |
| 8806083 | Doorenbos | Aug 2014 | B2 |
| 8873659 | Wang et al. | Oct 2014 | B2 |
| 8987933 | Yu | Mar 2015 | B2 |
| 10374583 | Olejarz et al. | Aug 2019 | B1 |
| 10649945 | Geerling | May 2020 | B1 |
| 20040122490 | Reinke | Jun 2004 | A1 |
| 20060125832 | Mawatari | Jun 2006 | A1 |
| 20060204007 | Doetzkies | Sep 2006 | A1 |
| 20070150629 | Lyle | Jun 2007 | A1 |
| 20070237332 | Lyle | Oct 2007 | A1 |
| 20080289003 | Bertin | Nov 2008 | A1 |
| 20090296938 | Devanand | Dec 2009 | A1 |
| 20110093221 | Dhanjal | Apr 2011 | A1 |
| 20120093342 | Rupprecht et al. | Apr 2012 | A1 |
| 20130124763 | Kessler | May 2013 | A1 |
| 20130148943 | Velasco | Jun 2013 | A1 |
| 20130200991 | Ricci | Aug 2013 | A1 |
| 20130212613 | Velasco | Aug 2013 | A1 |
| 20140025999 | Kessler | Jan 2014 | A1 |
| 20140095750 | Tailliet | Apr 2014 | A1 |
| 20140101351 | Hooper et al. | Apr 2014 | A1 |
| 20140101477 | Patterson | Apr 2014 | A1 |
| 20140223054 | Hasan et al. | Aug 2014 | A1 |
| 20140281077 | Biskup | Sep 2014 | A1 |
| 20140281078 | Biskup | Sep 2014 | A1 |
| 20140281079 | Biskup | Sep 2014 | A1 |
| 20140362865 | Chini et al. | Dec 2014 | A1 |
| 20150008960 | Lahr | Jan 2015 | A1 |
| 20150009050 | Lahr et al. | Jan 2015 | A1 |
| 20150032599 | Agapitov | Jan 2015 | A1 |
| 20150295903 | Yi | Oct 2015 | A1 |
| 20150301968 | Kessler | Oct 2015 | A1 |
| 20150365754 | Perl | Dec 2015 | A1 |
| 20160034416 | Chavez et al. | Feb 2016 | A1 |
| 20160034417 | Chavez et al. | Feb 2016 | A1 |
| 20160041941 | Kessler et al. | Feb 2016 | A1 |
| 20160196817 | Mortensen et al. | Jul 2016 | A1 |
| 20160295221 | Altmann | Oct 2016 | A1 |
| 20160315766 | Ujiie | Oct 2016 | A1 |
| 20170064370 | Wang | Mar 2017 | A1 |
| 20170134164 | Haga | May 2017 | A1 |
| 20170220502 | Kessler et al. | Aug 2017 | A1 |
| 20170222790 | Hooper et al. | Aug 2017 | A1 |
| 20170222829 | Kessler | Aug 2017 | A1 |
| 20170308352 | Kessler | Oct 2017 | A1 |
| 20170359499 | Thanigasalam | Dec 2017 | A1 |
| 20180060269 | Kessler | Mar 2018 | A1 |
| 20190023198 | Hu | Jan 2019 | A1 |
| 20190087377 | Srivastava | Mar 2019 | A1 |
| 20190173862 | Kim | Jun 2019 | A1 |
| 20190222423 | Takemori | Jul 2019 | A1 |
| 20190260800 | Shalev | Aug 2019 | A1 |
| 20190306136 | David | Oct 2019 | A1 |
| 20190330047 | Joginipelly | Oct 2019 | A1 |
| 20200004476 | Bush | Jan 2020 | A1 |
| 20200021775 | O'Connell | Jan 2020 | A1 |
| 20200044842 | Usui | Feb 2020 | A1 |
| 20200112439 | Kalaiselvam | Apr 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2013052886 | Apr 2013 | WO |
| Entry |
|---|
| “High-bandwidth Digital Content Protection System”. Revision 2.2. Intel Corporation. Dec. 21, 2012. (Year: 2012). |
| Liu, Jianhui. “Using SN65HVD96 to Create a Power-Over-Data and Polarity Immunity Solution”. Application Report SLLA-336. Texas Instruments, Inc. Jan. 2013. (Year: 2013). |
| CAN physical layer. CAN in Automation (CiA). Online Oct. 14, 2011. Retrieved from Internet Jun. 5, 2020. <https://web.archive.org/web/20111014023508/https://www.can-cia.org/index.php?id=systemdesign-can-physicallayer>. (Year: 2011). |
| MOST Informative, Issue 12, Apr. 2016, 32 pages. |
| MOST Automotive, Special Issue MOST, Mar. 2012, elektroniknet.de, 52 pages. |
| MOST Automotive, Microchip, www.microchip.com/wwwproducts/en/OS8119[10/30/2018], 6 pages. |
| MOST Automotive, Microchip, www.microchip.com/wwwproducts/en/OS82150[10/30/2018], 6 pages. |
| Unpublished U.S. Appl. No. 16/215,566, filed Dec. 10, 2018. |
| Unpublished U.S. Appl. No. 16/239,798, filed Jan. 4, 2019. |
| Unpublished U.S. Appl. No. 16/406,329, filed May 8, 2019. |
| Number | Date | Country | |
|---|---|---|---|
| 20200136858 A1 | Apr 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62843888 | May 2019 | US | |
| 62752028 | Oct 2018 | US |
