Redundant communication for multi-chip systems

Abstract

The electronic device includes a first component configured to transmit a first data set to a second component by providing a first memory request (706) identifying a first data set and an input memory address, and a transaction tracking unit (710) coupled to a first transmission interface (712). The transaction tracking unit (710) is configured to receive the first memory request (706), transmit a second memory request (716A) identifying at least a first portion of the first data set to the second component via the first transmission interface (712), receive a response (736A) to the second memory request from the second component, determine that the response (736A) corresponds to the second memory request, and provide an output response (738) to the first component based on the received response (736A) to the second memory request (716A).

Description

Background Art

[0001] Machine learning (ML) has become an increasingly important part of the computing environment. Machine learning is a type of artificial intelligence (AI), and ML helps enable software systems to recognize patterns and learn from data without directly programming it. A neural network (NN) is a type of ML that utilizes a set of weighted, linked, and hierarchical functions (e.g., nodes, neurons, etc.) to evaluate input data. In some NNs, which are sometimes referred to as convolutional neural networks (CNNs), a convolution operation can be performed in the NN layer based on the received input, and weighted CNNs are often used in a wide range of applications for recognition and classification, such as image recognition and classification, prediction and recommendation systems, speech and language recognition and translation.

[0002] As ML becomes increasingly useful, there is a desire to efficiently execute multiple complex ML techniques, such as NNs and CNNs, on devices with high availability. For example, for partially or fully automated driving applications, multiple ML models can be executed simultaneously in real time to identify, recognize, and / or predict objects, paths, trajectories, etc. These ML models may need to be made available even in cases where there are problems that can affect the performance of the ML models, such as performance degradation due to partial hardware failures, a large number of inputs, bad weather, etc.

Summary of the Invention

[0003] This description relates to an electronic device, the electronic device including a local component configured to transmit a first dataset to a second component by providing a first memory request and an input memory address that identify a first dataset, and a transaction tracking unit coupled to a first transmission interface, the transaction tracking unit receiving a first memory request, transmitting a second memory request that identifies at least a first portion of the first dataset to the second component via the first transmission interface, receiving a response from the second component to the second memory request, determining that the response corresponds to the second memory request, and providing an output response to the first component based on the received response to the second memory request.

[0004] Another aspect of the present invention relates to a circuit comprising a transaction tracking unit configured to receive a first message from a remote component via a first transmission interface, and a memory-mapped port coupled to the tracking unit, the memory-mapped port configured to output the first message to a local component and receive a response from the local component, the tracking unit further configured to determine that the received response corresponds to a first message from the remote component, and to output at least a first portion of the response to the remote component via the first transmission interface.

[0005] Another aspect of the description relates to a method for transmitting data, the method comprising: receiving from a first component to transmit first data relating to a mapped input memory address to a second component; transmitting at least a first portion of the first data to the second component via a first transmission interface; recording the status of the transmission to the second component; receiving a response to the transmission from the second component; determining that the response corresponds to a recorded transmission; and providing the response to the first component. [Brief explanation of the drawing]

[0006] For detailed explanations of various examples, please refer to the attached drawings.

[0007] [Figure 1] This is a block diagram of a processing system connected via redundant communication paths, according to the embodiment described herein.

[0008] [Figure 2] A block diagram shows the data flow according to the manner described herein.

[0009] [Figure 3A] This block diagram illustrates an exemplary operating mode for a Transaction Tracking and Distribution Module (TTDM) according to the embodiments described herein. [Figure 3B] This block diagram illustrates an exemplary operating mode for a Transaction Tracking and Distribution Module (TTDM) according to the embodiments described herein. [Figure 3C] This block diagram illustrates an exemplary operating mode for a Transaction Tracking and Distribution Module (TTDM) according to the embodiments described herein. [Figure 3D] This block diagram illustrates an exemplary operating mode for a Transaction Tracking and Distribution Module (TTDM) according to the embodiments described herein.

[0010] [Figure 4] This is a block diagram of TTDM in the transmission operation mode according to the embodiment described herein.

[0011] [Figure 5] This table illustrates a transaction mapping table in accordance with the configuration described herein.

[0012] [Figure 6] This is a block diagram of TTDM in the receiving operation mode according to the embodiment described herein.

[0013] [Figure 7]This is a block diagram illustrating the data flow between TTDMs according to the configuration described herein.

[0014] [Figure 8] This is a flowchart illustrating the technique for transmitting data in accordance with the manner described herein. [Modes for carrying out the invention]

[0015] Software incorporating ML (Machine Learning) techniques is increasingly being used in systems where high availability is desired, such as safety or mission-critical systems. Furthermore, the software used in such systems is becoming increasingly complex, which may indicate an increase in computing workload. Such systems can often be scaled to handle increasing workloads by having multiple computing cores, such as multiple central processing unit (CPU) cores, higher-performance or lower-performance CPU cores, ML cores, and graphics processing unit (GPU) cores, and by parallelizing the system through increased memory, communication links, etc., and the ability to run multiple software modules in parallel. For example, having multiple cores helps scale performance and provides a certain level of redundancy. For instance, multiple cores help provide redundancy in case of failure of one or more CPUs. Another example is that multiple cores can help increase the performance of chained software, where the output of one software module can be input to another module running in parallel. In some cases, redundant communication paths may be provided to help increase redundancy and availability.

[0016] Figure 1 is a block diagram 100 of components connected via redundant communication paths according to the embodiments described herein. As used herein, components include electronic devices that can access other components via a transmission interface. For example, components that can access other components may include processors, processor packages, controllers, direct memory access / I / O devices, etc. Accessible components may include other processors, processor packages, and / or controllers, and may include I / O devices, network devices, memory such as double data rate random access memory, and / or other types of random access memory, etc. As shown in the figure, block diagram 100 includes a first component 102, such as a processor core that can run a first application 104, such as an ML model or other software. In some cases, there may be a desire to send data to a second component 106, such as another processor core, for a second application 108, for example, the second application 108, which may be any software running on the second component 106 and including another instance of the first application 104. The first application 104 may transmit information to the second application 108 via the first transaction tracking and distribution module (TTDM) 110. The TTDM 110 may receive information via a proxy memory window, which is presented as a mapped memory region, from which an application or other process may provide memory requests by reading, writing, and / or other means. The first application 104 may pass information to the TTDM 110 by initiating a transaction, such as a read or write request, to the mapped memory region managed by the TTDM 110.

[0017] Mapped memory regions of a TTDM can provide access to a transmission interface through the TTDM. These mapped memory regions may correspond to the memory of the first TTDM110 (e.g., cache memory, registers, DRAM (Dynamic Random Access Memory)) rather than local memory. Mapped memory regions can be configurable in terms of size and may contain multiple regions rather than a single contiguous region. In some cases, one or more portions of a mapped memory region may be reserved for sending data to other components via the first TTDM110, and another or more portions may be reserved for receiving data from other components via the first TTDM110. In some cases, one or more portions of a mapped memory region may be reserved for instructions to the first TTDM110, and another or more portions may be reserved for data to be sent to other components. Using mapped memory regions to send and / or receive data with other components helps to isolate the transport protocol from the application, allowing the application to function using various transmission technologies.

[0018] After the first TTDM 110 receives information, it transmits one or more parts of the information to the second TTDM 112 of the second component 106 via one or more transmission technologies. The transmission technologies provide a data path between components. Examples of transmission technologies include bus architectures such as Peripheral Component Interconnect (PCI) buses, Ethernet, and hyperlink transmission. The first TTDM 110 is coupled with multiple transmission technologies, here being the first transmission technology 114 and the second transmission technology 116. Multiple transmission technologies can help provide redundancy in the communication path. The first TTDM 110 may determine whether to send a message from the first application 104 to the second TTDM 112 and the second application 108 via one or both of the transmission technologies 114 and / or 116. For example, the first TTDM 110 may duplicate the message and send it via both the first transmission technology 114 and the second transmission technology 116.

[0019] Figure 2 is a block diagram 200 showing a data flow according to the embodiment described herein. In this example, the SoC 202 may include a first set of CPU cores 204. In some cases, the SoC 202 may also include a second set of CPU cores 206. This second set of CPU cores 206 may be used to complement the first set of CPU cores 204, for example, by providing lower performance but consuming less power than the first set of CPU cores 204, or by being optimized for certain types of workloads, such as real-time or security applications. The SoC 202 may also include one or more DSP and / or ML cores 208, and memory 210. The SoC 202 includes an interconnect 212 that connects the components of the SoC 202 together and provides communication between the components. The SoC 202 also includes a memory controller module 214, including a TTDM 216. The SoC 202 also includes a set of transmission interface peripherals 218. The transmission interface peripheral 218 may include one or more components that can transmit or receive data and access data using a mapped memory area. In this example, the transmission interface peripheral 218 includes a first PCI Express (PCIe) interface 220, a second PCIe interface 222, a first hyperlink interface 224, and a second hyperlink interface 226. Here, the components included in the transmission interface peripheral 218 are examples, and other components accessible using transmission technology may also be included in the transmission interface peripheral 218.

[0020] TTDM216 can function as a proxy for communication between components. For example, if a component, such as the CPU cores of a first set of CPU cores 204, wants to send data to another component, such as a sensor, which is coupled via PCIe interfaces 220 and 222 and / or hyperlink interfaces 224 and 226, the CPU core can write the data, along with address information and / or instructions on how to send the data, to a memory area mapped to TTDM216 (240). Based on the address information and / or instructions on how to send the data, TTDM216 can determine the appropriate transmission technique to use. In some cases, a policy on how to send the data may be pre-configured. In this example, TTDM216 may determine, for example, based on address information, that the data is intended for components coupled via PCIe interfaces 220 and 222 and hyperlink interfaces 224 and 226. TTDM216 may determine which interface to use based, for example, instructions on how to transmit the data, PCIe interfaces 220 and 222 and / or hyperlink interfaces 224 and 226, and the configuration of TTDM216. TTDM216 then converts the data into a format compatible with the determined interface. For example, if TTDM216 determines to transmit data via the second PCIe interface 222, TTDM216 may convert the data into a PCIe-compatible format. Similarly, if TTDM216 determines to transmit data via both the PCIe interface and the hyperlink interface, TTDM216 may convert the data into a PCIe-compatible format and convert a copy of the data into a hyperlink-compatible format. TTDM216 then transmits the data via the determined interface (242). Response 244 may be received by TTDM216 via one or more interfaces, such as PCIe interfaces 220 and 222 and / or hyperlink interface 224.Next, TTDM216 may transfer this response to the CPU core (246).

[0021] The SoC202 in this example may also include a set of standard peripherals 228 that provide connectivity, services, and / or interfaces that are often available to the SoC202. In this example, the set of standard peripherals 228 includes a Universal Serial Bus (USB) 230, a Multimedia Card (MMC) 232, display 234 connectivity, and graphics operations 236 via, for example, a GPU or other image processing hardware. In some cases, the set of standard peripherals 228 may be coupled to a transmission interface and may include components accessible by the transmission interface. Such components of the standard peripherals 228 may initiate and participate in transactions with other components, such as a processor core, via the TTDM216.

[0022] Figures 3A to 3D are block diagrams illustrating exemplary operation modes for TTDM according to the described embodiments. TTDM may support multiple operation modes for transmitting and receiving data. In some cases, TTDM may be preconfigured to operate in a certain operation mode, or the operation mode for TTDM may be configurable. For example, TTDM switches between the multiple supported operation modes based on in which sub-region of the memory-mapped region of TTDM the memory operation is received. In FIG. 3A, TTDM 302 may be configured to operate in a load balancing mode. In this load balancing mode, TTDM 302 may receive input data from component 304. Then, TTDM 302 may determine which transmission technique 306 to use. This determination may be based on, for example, the load amount associated with transmission technique 306. For example, TTDM 302 may track the amount of data received on various transmission techniques 306 and then determine to use the transmission technique associated with the less transmitted amount of data. The load amount associated with the transmission technique may be estimated rather than directly measured. For example, TTDM 302 may determine which of the transmission techniques 306 to use based on a pattern or rotation. TTDM 302 may transmit a first data set related to the first transmission technique, a second data set related to the second transmission technique, and so on. In some cases, TTDM 302 may divide the data received from component 304 into multiple data sets and transmit these data sets via different transmission techniques. TTDM 302 may include an instruction on how to combine the data with the transmitted data sets. A second TTDM (not shown) may receive and combine the divided data sets based on an instruction on how to combine the data before transferring the data to a target component (e.g., a remote component).

[0023] In Figure 3B, the TTDM 302 may be configured to operate in a restricted bandwidth mode. In this restricted bandwidth mode, the TTDM 302 may receive data from a peripheral device 312. This data may include a credential instruction 314. Based on the credential instruction 314, the TTDM 302 may prioritize and / or determine the transmission technique for transmitting the data to the target component 316. For example, the data may include a credential instruction 314 indicating the priority associated with the data. Then, data associated with higher-priority credentials may be transmitted by the TTDM 302 using its transmission technique before data associated with lower-priority credentials. As another example, if there are multiple transmission techniques, the TTDM 302 may transmit data associated with higher-priority credentials over data associated with lower-priority credentials via different transmission techniques, thus helping to provide differential handling of quality of service. In yet another example with multiple transmission techniques, the TTDM 302 may transmit data associated with higher-security credentials over data associated with lower-security credentials via different transmission techniques.

[0024] In Figure 3C, the TTDM 302 may be configured to operate in any received response mode. In this received response mode, the TTDM 302 may receive data from component 322 for transmission to the target component. The TTDM 302 may then transmit multiple copies of the data via a plurality of transmission techniques, including a first transmission technique 324 and a second transmission technique 326. In this example, copies of the data are transmitted via the first transmission technique 324 and the second transmission technique 326. The TTDM of a target component (not shown) may receive one or more copies of the transmitted data and forward that data to the target component. The target component may then transmit a response to component 322 via its TTDM. The TTDM of the target component may use one or more transmission techniques. In some cases, the response may be transmitted using the same transmission techniques used to transmit the data, or using the same number of transmission techniques used to transmit the data. The response may also be transmitted using a different set of one or more transmission techniques.

[0025] In this example, the response may be transmitted via the same transmission techniques used to transmit the data, e.g., the first transmission technique 324 and the second transmission technique 326. As shown in this example, for several reasons, the response may not be received via the second transmission technique 326. For example, the response may not be received if the second transmission technique 326 fails to transmit data to the TTDM of the target component, or if the second transmission technique 326 fails to transmit the response to TTDM 302. In any received response mode, if any response is received, TTDM 302 may proceed to transmit the response to component 322. If multiple responses are received, TTDM 302 may transmit the first received response to component 322 and discard subsequent responses. If TTDM302 expects a response from the second transmission technique 326 and does not receive a response within the time frame, TTDM302 may send an instruction that the second transmission technique 326 has failed, for example, by issuing a warning. In this example, the number of transmission techniques 324 may be fewer than the total number of transmission techniques coupled to TTDM302.

[0026] Data may refer to data from and / or requests for data for the target component, and responses may refer to data requested from the target component, error messages, and / or acknowledgments.

[0027] In Figure 3D, the TTDM 302 may be configured to operate in best-of-N response mode. The initial transmission of data from component 332 via the TTDM 302 using the first transmission technique 334 and the second transmission technique 336, and the response from a target component (not shown) via its associated TTDM, may be substantially the same as those described above with respect to any received response mode. In this example, the response may be transmitted via the same transmission techniques used to transmit the data, e.g., the first transmission technique 334 and the second transmission technique 336. As shown in this example, the response may not be corrupted via the second transmission technique 336 for several reasons. For example, the response may be corrupted by electrostatic discharge, radiation-induced errors, bit flips, etc.

[0028] In best-of-N response mode, TTDM302 may include comparator logic 328 that compares responses received from transmission technologies. Comparator logic 328 can compare the received responses to determine which response is the best received. For example, if TTDM302 receives responses from three transmission technologies and two of those responses match, TTDM302 may proceed to transmit one of the matching responses to component 332. If there are an equal number of mismatched responses, comparator logic 338 may detect an error and take corrective action. In this example, comparator logic 338 may compare a response received via the first transmission technology 334 with a corrupted response received via the second transmission technology 336, determine that the two responses are different, and indicate that there was an error in the transmission. TTDM302 may then take corrective action, such as requesting retransmission, or transmit an instruction indicating that an error has been detected. For example, if, instead of the corrupted response in the above example, the response is received via the first transmission technique 334 and not via the second transmission technique 336, then TTDM 302 may proceed to send the response to component 332 because there was no response to compare with the received response.

[0029] Figure 4 is a block diagram 400 of TTDM450 in transmit operation mode according to the embodiment described herein. In Figure 4, the portion of TTDM450 used during transmit operation is shown, and TTDM may include the portion shown in both TTDM450 in Figure 4 and TTDM650 in Figure 6. As shown, TTDM450 includes a component port 402 which can be coupled to a requesting component (e.g., a local component). The component port 402 is coupled to a transaction tracking module 404, which includes a tracking whiteboard 406 and an input / output (I / O) buffer 408. The tracking whiteboard 406 may maintain a list of pending transactions of TTDM450 and record transactions sent to the target component in response to a response from the target component. The I / O buffer 408 may store data read from and written to the target component.

[0030] The component port 402 may also be coupled to other components, such as the distribution module 412, to help pass input information, such as credential information, to other components. The transaction tracking module 404 is coupled to the transaction mapping table 410, the distribution module 412, and the response handler module 414. The transaction mapping table 410 is coupled to and receives the configuration input from the configuration port 416. The transaction mapping table 410 helps track transactions and may include mappings between mapped memory addresses from the component port 402 to the target component address space. The configuration port 416 is also coupled to a set of control and status memory-mapped registers 418 configured to store control and status information about the TTDM 450. The transaction mapping table 410 may be coupled to and access the set of control and status memory-mapped registers 418 to help manage the operating mode.

[0031] The distribution module 412 may include a transaction generation module 420, a timeout handler module 422, and a load balancing module 424. The distribution module 412 may function as a configurable policy engine for managing the operating modes of the TTDM 450. The timeout handler module 422 may implement a timeout status machine for tracking whether an outstanding transaction has timed out. The load balancing module 424 may help balance transactions across multiple transmission technologies and may be configured to help manage credit-based load balancing, transmission technology-based rate limiting, or data-based rate limiting determined by data-related credentials. The distribution module 412 and the response handler module 414 may be coupled to a transmission port 426. The transmission port 426 may be coupled to one or more transmission technologies (not shown).

[0032] The TTDM450 can be configured via a configuration port 416. The configuration port 416 can be mapped to a configuration memory region such that writes to the configuration memory region are input to the configuration port 416. In some cases, the configuration memory region has a memory address separate from the mapped memory region of the TTDM450 that can be used for I / O operations.

[0033] In some cases, the mapped memory area of ​​the TTDM450 may contain two or more sub-areas that can accommodate various functions. For example, the sub-areas may correspond to different operating modes of the TTDM450. For instance, writing data to one sub-area may correspond to an instruction to send the written data via load balancing mode, while writing data to another sub-area may correspond to an instruction to send the written data via best-of-N response mode. The transaction mapping table 410 can help track the mapping of inputs from these sub-areas and requests sent to target components.

[0034] For example, a write request {WR, A} for writing data to a specific location A of a target component may be received on component port 402 in a memory sub-range of the mapped memory range of TTDM 450. This write request may be recorded on the tracking whiteboard 406 of the transaction tracking module 404 and sent to the distribution module 412. The transaction tracking module 404 may also send the memory sub-range in which the write request was received to the transaction mapping table 410 (428). The transaction mapping table 410 may then determine the operating mode corresponding to the memory sub-range in which the write request was received. The transaction mapping table 410 may send an instruction for the operating mode to the transaction generator 420. Based on the indicated operating mode, the transaction generator may address and convert the write request into a format compatible with one or more transmission technologies and send the converted write request to the transmission port 426 for output to one or more transmission technologies. For example, if the operating mode indicates that copies of a write request are to be sent via two transmission techniques, the transaction generator 420 may generate two copies of the write request and send these two copies of the write request to the transmission port 426 for output to the addressed transmission techniques (430). The first copy of the write request {Wr, A1} may be addressed to the first transmission technique of the two transmission techniques (A1). The second copy of the write request {Wr, A2} may be addressed to the second transmission technique of the two transmission techniques (A2). The tracking whiteboard may be updated to indicate that a write request for address A has been sent to the first address A1 of the first transmission technique and to address A2 of the second transmission technique, and that both of these requests are pending (e.g., [A, {A1, pend}, {A2, pend}]) (432).

[0035] Continuing this example, the target component may perform a write request and send a response via a first transmission technique {RespWR,A1} and a second transmission technique {RespWR,A2}. These responses may be received at the transmission port 426 and sent to the response handler 414 (434). The response handler 414 may record the response based on the operating mode of the TTDM 450. In this example, the TTDM 450 may be in any one response operating mode, and when a response is received via either the first or second transmission technique, the response handler 414 may store the response in the I / O buffer 408. The tracking whiteboard 406 may be updated to indicate that a response has been received for the write request. For example, if a response has been received via the first transmission technique but not via the second transmission technique, the tracking whiteboard 406 may be updated as [A,{A1,received},{A2,pend}]. In some cases, the tracking whiteboard 406 may record information about the operating mode associated with a transaction. This information may be used to determine when a response to the requesting component is appropriate (for example, when a single response is received, when the best of N responses is determined, etc.) and when a response (436) is sent for output by the component port 402.

[0036] Figure 5 is Table 500 illustrating a transaction mapping table according to the embodiment described herein. The transaction mapping table may be included in a transaction tracking module and maps a sub-region of a memory-mapped region to a certain operating mode of TTDM. As shown in the figure, the transaction mapping table may contain information defining multiple regions 1, 2, ... N corresponding to operating modes supported by TTDM. Each sub-region may be associated with a base memory address, the size of the sub-region, the operating mode corresponding to that region, and any parameters related to that operating mode. In some cases, the operating modes supported by TTDM may be predefined, and the characteristics of the operating mode, such as location, size, and the operating mode associated with a certain sub-region, may be configured, for example, by configuration information received via a configuration port.

[0037] Figure 6 is a block diagram 600 of the TTDM650 in receive operation mode according to the embodiments described herein. In Figure 6, the portion of the TTDM650 used during receive operation is shown, and the TTDM may include the portion shown in both the TTDM450 in Figure 4 and the TTDM650 in Figure 6. As shown, the TTDM650 includes a transmission port 602 which can be coupled to one or more transmission techniques (not shown) to a requesting component (e.g., a remote component). Similar to the TTDM450, the TTDM650 also includes a transmission port 602 coupled to a transaction tracking module 604, which includes a tracking whiteboard 606 and an input / output (I / O) buffer 608. The tracking whiteboard 606 may maintain a list of pending transactions of the TTDM650 and record transactions sent to the target component in response to a response from the target component. The I / O buffer 608 may store data read from and written to the target component.

[0038] The transaction tracking module 604 is coupled to the transaction mapping table 610, the distribution module 612, and the response generation module 614. The transaction mapping table 610 is coupled to and receives the configuration input from the configuration port 616. The transaction mapping table 610 helps track transactions and may include mappings between inputs received from source components via the transmission port 602 and component address spaces. The configuration port 616 is also coupled to a set of control and status memory-mapped registers 618 configured to store control and status information about the TTDM 650. The transaction mapping table 610 is coupled to and accesses the set of control and status memory-mapped registers 618 to help manage the operating mode. The distribution module 612 may include a transaction generation module 620 and a timeout handler module 622. The distribution module 612 may act as a proxy to generate local transactions to the mapped target memory area of ​​the target component. The timeout handler module 622 may implement a timeout state machine to track whether any outstanding transactions have timed out. The distribution module 612 may be coupled to a component port 626, which may be coupled to a target component (e.g., a local component). The component port 626 may be coupled to a transaction tracking module 604, which may be coupled to a response generator 614. The response generator 614 may be coupled to a transmission port 602. The response generator 614 may include a state machine implementation for generating a response to a source component and may implement a configurable operating mode on the target TTDM 650 side.

[0039] Tracking the behavior of the target TTDM650 when a write request is received, N write requests may be received at transmission port 602 from a source TTDM such as TTDM QE02. Continuing from the previous example described with respect to TTDM QE02 and Figure QE, two copies of the write request, {Wr,A1} and {Wr,A2}, may be received at transmission port 602 via the first and second transmission techniques, respectively. The write request, along with instructions from the source transmission techniques (e.g., {Wr,A,Src_A1}, {Wr,A,Src_A2}) that received the write request, may be passed to the transaction tracking module 604. The tracking whiteboard 606 may be updated to record that a write request for address A was received at address A1 of the first transmission technology and also at address A2 of the second transmission technology, and the status of the write request (e.g., [A,{SRC_A1,received},[SRC_A2,received}]). Address A of the received write request may be sent to the transaction mapping table 610, where the address of the write request may be translated to the corresponding address of the target component. This translated address may be input to the transaction generation module 620 to generate an appropriate write request (e.g., {Wr,A}) to output to the target component at component port 626. If multiple write requests are received for the same address, the transaction generation module 620 may merge the multiple write requests into a single write request to the target component. For example, the transaction generation module 620 may track outstanding requests to be sent to the target component.

[0040] The target component may, in response to a write request, output a single response (e.g., Resp{Wr,A}) at component port 626, which is input to TTDM 650. This response may be input from component port 626 to transaction tracking module 604. The tracking whiteboard may be updated to indicate that a response has been received from the target component (e.g., [A,{SRC_A1,resp.},{SRC_A2,received}]). In some cases, if transaction tracking module 604 receives another copy of a write request related to a write request that has already been completed, from another transmission technology, etc., transaction tracking module 604 may discard this copy of the write request. Transaction tracking module 604 may output the response to the write request and instructions for the transmission technology used to send the response to the write request (e.g., Resp{Wr,A1},Resp{Wr,A2}) to response generator 614. Depending on the circumstances, the output to the response generator 614 may be buffered in the I / O buffer 608. For example, if the response generator 614 is queuing responses to send or if the response generator 614 is busy, the response to the write request may be temporarily buffered. Depending on the circumstances, this instruction may be based on the transmission technology from which the write request was received. The response generator 614 may then generate a copy of the write request for the corresponding transmission technology and output the write request to the transmission port 602 for output to the appropriate transmission technology.

[0041] Figure 7 is a block diagram 700 illustrating the data flow between TTDMs according to the embodiment described herein. Figure 700 illustrates the data flow for a memory read request from a requesting TTDM 702 to a target TTDM 704. The requesting TTDM 702 may receive a read request 706 (e.g., {Rd, A}) from a requesting component (not shown) for address A for the target component. After receiving the read request 706, the tracking whiteboard 708 of the transaction tracking module 710 may be updated. The tracking whiteboard 708 may record information including the read address (e.g., Addr) of the read request, as well as address information (e.g., addr) and request status (e.g., status) for copies of the read request (R1, R2) that may be sent via different transmission technologies. In this example, two copies of the read request for address A may be translated to address A1, corresponding to the address space for a first transmission technology, and address A2, corresponding to the address space for a second transmission technology. The tracking whiteboard 708 may record that the read request relates to copies of read requests for A1 and A2, both of which are pending (e.g., [A,{A1,pend},{A2,pend}]). A write-back index on the tracking whiteboard 708 may be used to identify where the entry corresponding to the read request is located on the tracking whiteboard 708. The transaction tracking module 710 may also allocate space in a receive buffer 752 (e.g., an I / O buffer) to store the response to the copy of the read request (750). The receive buffer 752 may also include the address from which the read request was sent, a pointer to a first first-in, first-out buffer space (FIFO) for the response, and a write-back pointer to the tracking whiteboard 708 index. Two copies of the read request (e.g., {Rd,A1} and {Rd,A2}) may be placed at the output ports of the mapped memory addresses corresponding to the first transmission technique 712 (e.g., A1) and the second transmission technique 714 (e.g., A2), and may be transmitted to the target TTDM 704 using the corresponding transmission techniques (716A and 716B).

[0042] In target TTDM704, a copy of a read request may be received at an input port of an address mapped to a transmission technology. In this example, a first copy of the read request may be received at address A1 mapped to a first transmission technology 718, and a second copy of the read request may be received at address A2 corresponding to a second transmission technology 720. The received read request, along with a source indication showing the transmission technology (e.g., Src_A1 and Src_A2) from which the read request was received, may be input to the transaction tracking module 722 of target TTDM704. The tracking whiteboard 724 of target TTDM704 may be updated with information about the received read request. The tracking whiteboard 724 may record the address of the read request (e.g., Addr), as well as address information (e.g., SRC1-addr, SRC2-addr) and the corresponding request status for the received copies of the read request. In this example, the tracking whiteboard 724 has an entry [A,{SRC_A1,recvd}, {SRC_A2,responded}] indicating that there is a read request to address A, this entry indicates that a first copy of this request was received at address A1 corresponding to a first transmission technique, a second copy of this request was received at address A2 corresponding to a second transmission technique, and a response was received from this component. For example, transmission techniques may not be synchronized, and some requests may arrive before others. In some cases, a message relating to a certain transmission technique may be relayed through other components (not shown). If the tracking whiteboard 724 indicates that no response has been received for a copy of the read request, a single read request 728 (e.g., {Rd,A}) for address A may be sent to the target component.

[0043] The transaction tracking module 722 may also allocate space within the send buffer 726 to receive responses to read requests from components. The send buffer 726 may include address A of the read request, a pointer to a FIFO space for storing response data, and a pointer to a tracking whiteboard 724 index. The send buffer 726 may have a single space allocated such that a single response is expected from the target component.

[0044] Next, the target component may send a response 730 (e.g., Resp{Rd,A}) to the target TTDM 704, which will be passed to the transaction tracking module 722. This response may be stored in the send buffer 726, and the tracking whiteboard 724 may be updated to indicate that the response has been received. The transaction tracking module 722 may then have a copy of the response generated and sent via the transmission technology from which the request was received. In this example, the tracking whiteboard 724 indicates that the source of the read request was address A1 corresponding to the first transmission technology and address A2 corresponding to the second transmission technology, so two copies of the response (e.g., Resp{Rd,A1} and Resp{Rd,A2}) may be generated and sent to address A1 corresponding to the address space for the first transmission technology and address A2 corresponding to the address space for the second transmission technology (732A and 732B). These copies may be placed at the output ports of mapped memory addresses corresponding to the first transmission technique 718 (e.g., A1) and the second transmission technique 720 (e.g., A2), and may be transmitted to the requesting TTDM 702 via the corresponding transmission techniques (734A and 734B).

[0045] In the requesting TTDM 702, a copy of the response may be received at an input port of an address mapped to a transmission technique. In this example, a first copy of the read request may be received at address A1 mapped to a first transmission technique 712, and a second copy of the read request may be received at address A2 corresponding to a second transmission technique 714. The received responses (e.g., Resp{Rd,Src_A1} and Resp{Rd,Src_A2}) may be input to the transaction tracking module 710 of the supplying TTDM 702, along with a source indication showing the transmission technique (e.g., Src_A1 and Src_A2) from which the response was received (736A and 735B). The transaction tracking module 710 may determine that the received response satisfies the operating mode associated with the read request (e.g., any received response mode, best of N response mode, etc.). Next, the transaction tracking module 710 may select a copy of the received response (e.g., Resp{Rd,A}) and place the received response on the output port for output 738 to the requesting component.

[0046] As shown in the figure, a fail-safe domain 740 may be defined by the requesting TTDM 702 and the target TTDM 704, where a certain level of redundancy may be provided against errors when a single request is converted into multiple independent requests and sent to the target component and, conversely, when responses are sent to the source component.

[0047] Figure 8 is a flowchart 800 illustrating a technique for transmitting data according to the embodiments described herein. This technique may be implemented by electronic devices and / or circuits. Instructions for implementing this technique may be stored in non-temporary computer-readable media, such as semiconductor-based memory devices including flash storage, magnetic disks, optical media, electrically programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM). In block 802, first data related to a mapped input memory address for transmission to a second component is received from the first component via the mapped input memory address. For example, a local component may send data to a mapped memory location in the TTDM for transmission to a remote component (e.g., a target component). The TTDM may receive the data via the memory-mapped input memory address. The TTDM may receive the data and determine an operating mode. The operating mode may be determined based on the memory range of the mapped memory input memory address from which the data was received. In block 804, at least a first portion of the first data is transmitted to the second component via the first transmission interface. Optionally, TTDM may transmit the data using a determined operating mode. For example, TTDM may be coupled to multiple transmission technologies via multiple transmission interfaces. Based on the determined operating mode, TTDM may determine which of the multiple transmission technologies to use to transmit the data. For example, the choice of transmission technology may be determined based on the load on the transmission technology, the credentials associated with the data, and / or an instruction that multiple transmission technologies should be used. In block 806, the status of the transmission to the second component may be recorded. For example, the status of pending transmissions to remote components may be recorded by TTDM. In block 808, a response to the transmission is received from the second component. For example, the response may be received via one or more transmission technologies. In block 810, the response is determined to correspond to the recorded transmission.For example, a response may include instructions for a corresponding request, and TTDM may map the response to the corresponding recorded request and update the tracking information. In block 812, the response is provided to a first component. For example, the contents of the response may be written to a portion of the mapped memory area in order to output the contents of the response to a local component.

[0048] Depending on the circumstances, another electronic device and / or circuit may implement a technique for receiving transmitted data. Instructions for implementing this technique may be stored in a non-temporary computer-readable medium. This technique may include receiving a first message from a remote component via a first transmission interface. For example, TTDM may receive data from a remote component via a certain transmission technique. Depending on the circumstances, a component may be coupled to a second transmission interface, and the component may further receive second data from the second transmission interface. The received second data may be associated with the first message. For example, both the first and second data may include an indicated address for a target component, and the first and second data may be merged into a single request. In some examples, the first and second messages may be compared and it may be determined that the first and second messages are different. An instruction indicating that an error has been detected may then be output.

[0049] This technique may also include outputting a first message to a local component. For example, TTDM may output a message to a local component. TTDM may record the message to help determine the status of the message. Output may be done via a memory-mapped port. A memory-mapped port may be represented as a memory-mapped region. This technique may also include receiving a response from a local component. For example, a local component may receive a message and send a response to that message to TTDM. This technique may also include determining that the received response corresponds to a first message from a remote component. For example, the response may include an indication of the message to which the response corresponds, and TTDM may update the message record. A response may be received via a memory-mapped input memory address. A response may be received and the operating mode may be determined. A response may be determined based on the memory range of the mapped memory input memory address from which the response was received. This technique may also include outputting at least a first portion of the response to a remote component via a first transmission interface. For example, a TTDM may output a portion of its response to a transmission technology for transmission to a remote TTDM. Depending on the circumstances, a TTDM may transmit the response by applying a determined operating mode. For example, a TTDM may be coupled to multiple transmission technologies via multiple transmission interfaces. Based on the determined operating mode, a TTDM may determine which of the multiple transmission technologies to use to transmit the response.

[0050] In this description, the term “to be coupled” may include connections, communications, or signaling paths that enable a functional relationship consistent with this description. For example, if device A generates a signal to control device B in order to perform a certain operation, then (a) in the first example, device A is coupled to device B by a direct connection, or (b) in the second example, device A is coupled to device B via an intervening component C, in which case the intervening component C does not alter the functional relationship between device A and device B such that device B is controlled by device A via a control signal generated by device A.

[0051] Modifications to the described embodiments are permitted within the scope of the claims, and other embodiments are possible.

Claims

1. It is an electronic device, A first component, configured to transmit the first dataset to a second component by providing a first memory request and an input memory address that identify the first dataset, A transaction tracking unit coupled to a first transmission interface and a second transmission interface, wherein, based on a transmission policy, Upon receiving the first memory request, A second memory request specifying at least a first portion of the first dataset is transmitted to the second component via the first transmission interface. The first version of the response to the second memory request is received from the second component via the first transmission interface. A second version of the response to the second memory request is received from the second component via the second transmission interface. This includes comparing the first version with the second version to determine whether the first version and the second version are the same, and determining that the response corresponds to the second memory request. Based on the comparison operation, an output response is provided to the first component. The transaction tracking unit is configured as follows: Electronic devices, including those mentioned above.

2. The electronic device according to claim 1, An electronic device in which the transaction tracking unit is presented to the first component as a memory-mapped region.

3. The electronic device according to claim 2, An electronic device in which the transmission policy of the transaction tracking unit is based on a sub-region of the memory-mapped region where the input memory address is located.

4. The electronic device according to claim 1, An electronic device wherein the transaction tracking unit is further configured to transmit at least a second portion of the first dataset to the second component via the second transmission interface, based on the transmission policy.

5. The electronic device according to claim 4, An electronic device in which the first transmission interface is a transmission interface of a different type from the second transmission interface.

6. The electronic device according to claim 4, An electronic device in which the second part is a copy of the first part.

7. The electronic device according to claim 1, The transaction tracking unit, based on the transmission policy, A third memory request is received that identifies the second dataset. Based on the first type of data associated with the first dataset and the second type of data associated with the second dataset, the transmission order of the portions of the first dataset and the second dataset is determined. Based on the transmission order, the first dataset and the second dataset are transmitted. An electronic device further configured in this way.

8. The electronic device according to claim 1, An electronic device wherein the transaction tracking unit is further configured to receive the response via either the first transmission interface or the second transmission interface.

9. The electronic device according to claim 1, An electronic device further configured such that the transaction tracking unit provides the first component with either the first or second version of the response via the output response when it is determined, based on the transmission policy, that the first version and the second version are the same.

10. The electronic device according to claim 1, An electronic device further configured such that the transaction tracking unit outputs an instruction indicating that an error has been detected when it is determined, based on the transmission policy, that the first version and the second version are different.

11. It is an electronic device, A first component configured to transmit the first dataset to a second component by providing a first memory request and an input memory address that identify the first dataset, Transaction tracking units coupled to the first, second, and third transmission interfaces, which, based on a certain transmission policy, Upon receiving the first memory request, A second memory request specifying at least a first portion of the first dataset is sent to the second component via the first transmission interface. The set of responses is received via the first, second, and third transmission interfaces. If at least two of the responses in the response set are the same, and the response set is compared to determine the output version of the response, The output version of the above response is provided as the output response. The transaction tracking unit is configured as follows: Electronic devices, including those mentioned above.

12. It is a circuit, A transaction tracking unit, A first message is received from a remote component via a first transmission interface. The remote component receives a second message via a second transmission interface. The second message is mapped to the first message. The transaction tracking unit is configured as follows: A memory-mapped port connected to the transaction tracking unit, The first message is output to the local component, The local component receives a response from the aforementioned local component. The memory-mapped port is configured as follows: Includes, The transaction tracking unit, It is determined that the received response corresponds to the first message from the remote component, At least a first portion of the response is output to the remote component via the first transmission interface. A circuit further configured in this way.

13. The circuit according to claim 12, A circuit in which the transaction tracking unit is presented to the local component as a memory-mapped region.

14. The circuit according to claim 12, A circuit further configured such that the transaction tracking unit outputs at least a second portion of the response to the remote component via the second transmission interface based on a certain transmission policy.

15. The circuit according to claim 12, The transaction tracking unit, In order to determine that the first message and the second message are different, the first message and the second message are compared, Outputs an instruction indicating that an error has been detected. A circuit further configured in this way.

16. The circuit according to claim 12, The transaction tracking unit, Determine the transmission technology on which the first and second messages were received. Based on the determined transmission technology, the first part of the response and the second part of the response are output. A circuit further configured in this way.

17. A method for transmitting data, Receiving from the first component data related to an input memory address mapped for transmission to the second component, Transmitting at least a first portion of the first data to the second component via a first transmission interface, Recording the instruction to transmit to the second component, Receiving a first version of the response to the transmission from the second component via the first transmission interface, Receiving a second version of the response from the second component via a second transmission interface, Determining that the response corresponds to the recorded transmission instruction, the determination includes comparing the first version with the second version in order to determine whether the first version and the second version are the same, Based on the above comparison, the response is provided to the first component, Methods that include...

18. The method according to claim 17, A method further comprising transmitting at least a second portion of the first data to the second component via the second transmission interface.

19. The method according to claim 18, A method wherein the first transmission interface is a transmission interface of a different type from the second transmission interface.

Images