TECHNICAL FIELD

[0001] This disclosure relates to data transactions between devices.

BACKGROUND

[0002] In a network system, numerous master devices (e.g., primary devices) can be connected to a slave device (e.g., a secondary device) via a bus. For example, the master devices can initiate data transactions with the slave device. Furthermore, the master devices can control the slave device and/or processes associated with the slave device. As such, data transactions can be transmitted and/or received between master devices and a slave device. In an example, a particular master device can send a data request to a slave device. As such, a slave device can send a data response to a particular master device in response to receiving a data request. However, in certain instances, a slave device may be unable to send a data response to a particular master device (e.g., due to device failure, etc.). As such, a network hang (e.g., a network freeze, a system bus hang, a system bus freeze, etc.) can occur in the network system.

SUMMARY

[0003] In an embodiment, a system comprises an interface component and a timeout component. The interface component is configured for receiving a data request from a master device and forwarding the data request to a slave device. The timeout component is configured for maintaining a clock counter associated with the data request. The timeout component is also configured for generating a timeout signal in response to a determination that a threshold level associated with the clock counter is reached before receiving a data response associated with the data request from the slave device.

[0004] In another embodiment, a method comprises receiving a data request in a computer system from a master device. The method also comprises forwarding the data request to a slave device. The method also comprises maintaining a clock counter associated with the data request in the computer system. The method also comprises generating a timeout signal in the computer system in response to a determination that a threshold level associated with the clock counter is reached before receiving a data response associated with the data request from the slave device.

[0005] In another embodiment, a system includes a means for receiving a data request from a master device. The system also includes a means for forwarding the data request to a slave device. The system also includes a means for maintaining a clock counter associated with the data request. The system also includes a means for generating a timeout signal in response to a determination that a threshold level associated with the clock counter is reached before receiving a data response associated with the data request from the slave device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 is a block diagram illustrating an embodiment of a network system.

[0007] FIG. 2 is a block diagram illustrating another embodiment of a network system.

[0008] FIG. 3 is a block diagram illustrating another embodiment of a network system.

[0009] FIG. 4 is a block diagram illustrating a slave shim interconnect within a network system.

[0010] FIG. 5 is a block diagram illustrating data transaction signals in connection with a slave shim interconnect.

[0011] FIG. 6 illustrates a flow diagram of an embodiment of a method for generating a timeout signal based on a clock counter associated with a data request.

[0012] FIG. 7 illustrates a flow diagram of an embodiment of a method for implementing data transactions in connection with a slave shim interconnect.

[0013] FIG. 8 illustrates a flow diagram of another embodiment of a method for implementing data transactions in a slave shim interconnect.

[0014] FIG. 9 illustrates a flow diagram of another embodiment of a method for implementing data transactions in a slave shim interconnect. [0015] FIG. 10 illustrates a flow diagram of an embodiment of a method for processing a data request.

[0016] FIG. 11 illustrates a flow diagram of an embodiment of a method for processing a data response.

[0017] FIG. 12 illustrates a block diagram of an example electronic computing environment.

[0018] FIG. 13 illustrates a block diagram of an example data

communication network.

DETAILED DESCRIPTION

[0019] Various aspects of the present disclosure facilitate a timeout mechanism for data transactions (e.g., data requests and/or data responses) based on a clock counter associated with the data transactions. For example, one or more data responses can be generated on behalf of a slave device when the slave device is unable to generate the one or more data responses (e.g., due to a slave device failure). In an aspect, a timeout mechanism can be implemented to facilitate generation of one or more data responses on behalf of a slave device when the slave device is unable to generate the one or more data responses. In one example, a timeout mechanism can be associated with a clock counter (e.g., a timer). As such, a data response can be guaranteed for each data request generated by a master device. Therefore, a network hang (e.g., a network freeze, a system bus hang, a system bus freeze, etc.) can be avoided. Accordingly, resetting of a network system due to a network hang can be avoided. Furthermore, other slave devices can continue to receive data requests and/or send data responses via the system bus.

[0020] FIG. 1 is a block diagram illustrating an embodiment of a system 100. System 100 includes a slave shim interconnect 102, at least one master device (e.g., primary device) 104 and a slave device (e.g., secondary device) 106. For example, the at least one master device 104 and the slave device 106 can be coupled via a bus (e.g., a system bus) 2. As such, one or more master devices can be in communication with the slave shim interconnect 102 via the bus 112. The system 100 can include a slave shim interconnect for each slave device in the system 100 (e.g., the system 100 can include more than one slave shim interconnect and/or more than one slave device). The slave shim interconnect 102 can include at least an interface component 108 and a timeout component 110. The system 100 can be employed by various systems, such as, but not limited to server systems, high availability server systems (e.g., Telecom server systems), Web server systems, file server systems, media server systems, network systems, TCP network systems, internet network systems, data center systems, communication systems, router systems, disk array systems, powered insertion board systems, and the like.

[0021] The slave shim interconnect 102 can be implemented as an interconnect layer of the slave device 06. For example, the slave shim interconnect 102 can be implemented between a first interface of the slave device 106 (e.g., a bus-side interface) and a second interface of the slave device 106 (e.g., a device-side interface). In another aspect, the slave shim interconnect 102 can be implemented separate from the slave device 106. For example, the slave shim interconnect 102 can be coupled to and/or in communication with the slave device 106. In an aspect, the master device 104 can be implemented as a central processing unit. However, the master device 104 can be implemented as a different type of device. In an aspect, the slave device 106 can be a network device (e.g., a server device). For example, the slave device 106 can be implemented as a peripheral component interconnect (PCI) device. However, the slave device 106 can be implemented as a different type of network device. In another aspect, the slave device 106 can be a storage device. For example, the slave device can be implemented as a serial advanced technology attachment (SAT A) device. However, the slave device 106 can be implemented as a different type of storage device.

[0022] The slave shim interconnect 102 (e.g., the interface component 108) can be configured to receive one or more data requests from the master device 104 (e.g., via a bus 112). For example, the slave shim interconnect 102 (e.g., the interface component 108) can be configured to receive one or more read requests from the master device 104. Additionally, the slave shim interconnect 102 (e.g., the interface component 108) can be configured to receive one or more write requests from the master device 104. In an aspect, the one or more data requests can be Advanced extensible Interface (AXI) data requests. [0023] Furthermore, slave shim interconnect 102 (e.g., the interface component 108) can be configured to send (e.g., forward) the one or more data requests (e.g., the one or more data requests received from the master device 104) to the slave device 106. In an aspect, the slave shim interconnect 102 can receive and/or send (e.g., forward) a single data request. In another aspect, the slave shim interconnect 102 can receive and/or send (e.g., forward) a group of data requests. As such, the slave shim interconnect 102 can be an interconnect device (e.g., an intermediary device) for data transmissions between the master device 104 and the slave device 106.

[0024] The interface component 108 can be configured to monitor data transactions (e.g., data requests and/or data responses) between the master device 104 and the slave device 106. In an aspect, the interface component 108 can be configured to monitor data transactions between the master device 104 and the slave device 106 based at least in part on a timeout mechanism (e.g., a clock counter, a timer, etc.) associated with the timeout component 110. For example, the timeout component 110 can implement at least one clock counter (e.g., at least one timer) associated with a data request received from the master device 104 and/or sent to (e.g., forwarded to) the slave device 106. In an aspect, the timeout component 110 can implement a clock counter for each data request received by the interface component 08. The timeout component 110 can maintain a plurality of clock counters corresponding to a total number of data requests received from the at least one master device 104.

[0025] Therefore, in an aspect, the interface component 108 can receive a data request from the master device 104 and/or forward the data request to the slave device 06. Furthermore, the timeout component 10 can maintain a clock counter associated with the data request. In an aspect, the timeout component 110 can generate a timeout signal (e.g., an error response signal) in response to a determination that a threshold level associated with the clock counter is reached (e.g., a timer has expired) before receiving a data response associated with the data request from the slave device 06. The threshold level can correspond to a predetermined period of time since the forwarding of the data request to the slave device 106. As such, the interface component 108 can detect a timeout signal and/or generate an error response associated with a data request. In an aspect, the clock counter implemented by the timeout component 110 can be triggered by a signal (e.g., a periodic 'tick' signal). For example, the clock counter implemented by the timeout component 110 (e.g., a timeout field associated with the data request) can be incremented by one (e.g., a single value) based on the signal. In an aspect, the threshold level can be associated with a hexadecimal value (e.g., OxFF, etc.). However, the threshold value can be associated with a different type of value. Accordingly, the clock counter implemented by the timeout component 110 (e.g., a timeout field associated with the data request) can be incremented by a single hexadecimal value based on the signal.

[0026] In an aspect, the interface component 108 can be configured to send a proxy data response associated with the data request to the master device 104 as a function of the at least one clock counter (e.g., the timeout mechanism) associated with the timeout component 110. For example, the interface component 108 can be configured to send a proxy data response to the master device 104 in response to receiving the timeout signal from the timeout component 1 10 (e.g., in response to a determination that the master device 104 has not received a data response associated with the data request from the slave device 106 within a predetermined time period). The interface component 108 can send a proxy data response to the master device 104 on behalf of the slave device 06 in response to a determination that the master device 104 has not received a data response (e.g., a data response associated with the data request generated by the master device 104) from the slave device 106 within a predetermined time period. In an aspect, the predetermined time period can be programmable and/or configurable. In one example, the predetermined period of time can be determined based on information associated with the slave device 106. The predetermined period of time can be determined based on information associated with the master device 104 that generated the data request. The predetermined period of time can be determined based on information associated with the data request. A predetermined period of time associated with a particular data request can be different than a predetermined period of time associated with a different data request (e.g., a predetermined period of time can be uniquely determined for each data request). In another example, the predetermined period of time can be determined and/or configured by a user (e.g., user input). Accordingly, greater flexibility can be provided by allowing timeout values (e.g.,

predetermined time periods) to vary for different slave interfaces.

[0027] Furthermore, the interface component 108 and/or the timeout component 110 can be configured to handle one or more other data requests (e.g., future data requests) associated with the slave device 106 in response to the receiving the timeout signal from the timeout component. For example, the interface component 108 can receive one or more other data requests (e.g., after the initial data request) from the master device 104 and/or send one or more other data responses (e.g., after the proxy data response) to the master device 104 on behalf of the slave device 106 in response to the determination that the master device 104 has not received a data response associated with the data request from the slave device 106 within a predetermined time period. As such, the interface component 108 and/or the timeout component 110 can takeover (e.g., manage, control, etc.) any impending data requests and/or data responses for the slave device 106 after the proxy data response is sent to the master device 104 (e.g., in response a clock counter associated with a data request reaching a threshold value, in response a timer associated with a data request expiring, in response to a timeout signal being generated, etc.). In an aspect, a data response and/or a proxy data response can be an AXI data response. In another aspect, the interface component 108 can send a data response and/or a proxy data response according to a set of ordering rules (e.g., a set of AXI ordering rules).

[0028] In an aspect, the interface component 108 can forward a data response associated with the data request to the master device 104 in response to receiving the data response from the slave device 106 and not receiving the timeout signal from the timeout component 110. For example, if a data response associated with the data request is generated by the slave device 106 within the predetermined period of time (e.g., before the clock counter reaches the predetermined threshold value, before the timer expires, etc.), the interface component 108 can forward the data response to the mater device 104.

Accordingly, the interface component 108 can forward a data response to the master device 104 instead of generating and/or sending a proxy data response.

[0029] In another aspect, the interface component 108 can be configured to store a transaction identification (ID) associated with the data request. For example, the interface component 108 can store a transaction ID associated with the data request in response to receiving the data request from the master device 104 and/or in response to sending (e.g., forwarding) the data request to the slave device 06. The interface component 108 can be configured to store information associated with the transaction ID and/or the data request. For example, the information associated with the transaction ID and/or the data request can include a tag (e.g., an input/output bride request tag), information associated with length of the data request, a register request flag (e.g., a flag that indicates whether the data request is a register request), a control or status register request flag (e.g., a CSR request flag), a timeout count associated with the data request (e.g., a clock counter value associated with the data request), information regarding other data requests associated with the transaction ID, and/or other information associated with the transaction ID and/or the data request.

[0030] The interface component 108 and/or the timeout component 110 can determine whether a data response and/or a proxy data response associated with a particular data request has been sent to the master device 104 based on a corresponding transaction ID (e.g., associated with the data request) stored by the interface component 108. In another aspect, the interface component 108 can be configured to manage stored transactions IDs. In one example, the interface component 108 can be configured to delete the transaction ID associated with the data request in response to receiving the data response associated with the data request from the slave device 106. In another example, the interface component 108 can be configured to delete the transaction ID associated with the data request in response to the sending of the proxy data response associated with the data request. In an aspect, the interface component 108 can append a transaction ID for a data request to a corresponding data response and/or a corresponding proxy data response. For example, the interface component 108 can be configured to associate a transaction ID associated with a data request with a corresponding data response and/or a corresponding proxy data response (e.g., a corresponding data response and/or a corresponding proxy data response can comprise a transaction ID for the data request). [0031] Therefore, the interface component 108 can determine whether to send a proxy data response associated with a data request based at least in part on a transaction ID stored and/or deleted by the interface component 108. In an aspect, the timeout component 1 0 can be configured to manage and/or update clock counters (e.g., timers) associated with data requests. For example, the timeout component 110 can stop and/or delete (e.g., remove) a clock counter (e.g., a timer) associated with a data request in response to a corresponding data response and/or a corresponding proxy data response being sent to the master device 104.

[0032] In an aspect, the timeout component 110 can periodically scan for transaction IDs that have not received a response from the slave device 106. Therefore, when a response for a pending data request has not been received within a predetermined period of time (e.g., a predetermined window of time), the timeout component 110 can generate a timeout signal. In another aspect, when a response for a pending data request has not been received within a predetermined period of time (e.g., a predetermined window of time), an interface associated with the slave device 106 can be disabled.

[0033] FIG. 2 is a block diagram illustrating an embodiment of a system 200. System 200 includes the slave shim interconnect 102, the at least one master device 104 and the slave device 106. The slave shim interconnect 102 can include at least the interface component 108 and the timeout component 110. The interface component 108 can include a transaction identification (ID) component 202 and/or an order component 204.

[0034] The transaction ID component 202 can maintain (e.g., store) a transaction ID for each data request received by the master device 104 in a data structure (e.g., a storage device, a data store, etc.). For example, the transaction ID component 202 can maintain (e.g., store) transaction IDs that are associated with pending data requests. In an aspect, the transaction ID component 202 can be implemented as and/or associated with a first-in-first-out (FIFO) data structure. In another aspect, the transaction ID component 202 can be associated with a content-addressable memory. In another aspect, the transaction ID component 202 can maintain (e.g., store) a transaction ID for each data request in a linked list data structure. In one example, a transaction ID stored in the data structure can be associated with a single data request. In another example, a transaction ID stored in the data structure can be

associated with more than one data request. For example, an entry in the data structure for a transaction ID (e.g., an entry for a data list in a linked list data structure) can be configured based on ordering of data requests to be processed. Accordingly, the transaction ID component 202 (e.g., a linked list data structure implemented in and/or associated with the transaction ID component 202) can be configured to track pending data requests associated with the slave device 106. For example, a data response and/or a proxy data response for a pending data request can be generated based at least in part on a determination that the pending data request is a next data request to be processed in a linked list data structure (e.g., in a data list of the linked list data structure). The transaction ID component 202 can facilitate management of data request(s) associated with each transaction ID (e _; g., ordering of data request(s) associated with each transaction ID, tracking of pending data request(s) associated with each transaction ID, etc.).

[0035] In an aspect, the transaction ID component 202 can include and/or be associated with one or more data structures to support ordering of data requests. For example, a first data structure can store transaction IDs associated with pending data requests, a second data structure can include an index of the first data structure (e.g., hit or miss information for each transaction ID), a third data structure can store information associated with pending data requests, a fourth data structure can store output information for a next pending data request, a fifth data structure can store information for a next data request that requires a data response in each linked list of transaction IDs, a sixth data structure can store information for a last data request that requires a data response in each linked list of transaction IDs, a seventh data structure can include an array of buffers for storing information associated with each pending data request, etc.

[0036] The order component 204 can be configured to manage received data requests. The order component 204 can be configured to manage sending of data responses and/or proxy data responses. In an example, the order component 204 can manage sending of data responses and/or proxy data responses based at least in part on transaction IDs stored in the transaction ID component 202. The order component 204 can be configured to monitor and/or receive timeout signals associated with the timeout component 110. For example, the order component 204 can be configured to receive and/or store data requests (e.g., determine whether to process data requests on behalf of the slave device 106) based on timeout signals generated by the timeout component 110. The order component 204 can generate data responses and/or proxy data responses (e.g., determine whether to send a data response and/or a proxy data response for a particular data request) based on timeout signals generated by the timeout component 110.

[0037] The order component 204 can be configured to manage stored transaction IDs. In an aspect, the order component 204 can update and/or delete stored transaction IDs. For example, the order component 204 can associate a transaction ID for a data request with a corresponding data response. In another example, the order component 204 can associate a transaction ID for a data request with a corresponding proxy data response. In an aspect, the order component 204 can delete a transaction ID associated with the transaction ID component 202 in response to being associated with a data response and/or a proxy data response. The order component 204 can manage transaction IDs associated with data transactions (e.g., data requests and/or data responses associated with the transaction ID component 202).

[0038] In an aspect, the order component 204 can process a data request associated with a first transaction ID and/or a data response associated with a second transaction ID per clock cycle. For example, during each clock cycle, the order component 204 can process a data request associated with a particular transaction ID and/or a data response associated with a different transaction ID. In another aspect, in response to an ID collision during a particular clock cycle, the order component 204 can process a data response associated with a particular transaction ID before a data request associated with the particular transaction ID.

[0039] FIG. 3 depicts a block diagram illustrating an embodiment of a system 300. System 300 includes the slave shim interconnect 102, the at least one master device 104 and the slave device 106. The slave shim interconnect 102 can include at least the interface component 108, the timeout component 110 and a slave control status register (CSR) component 302. The interface component 108 can include the transaction ID component 202 and/or the order component 204.

[0040] The slave CSR component 302 can be configured to receive one or more data requests and/or send one or more data responses associated with the slave register(s) 304 (e.g., at least one CSR register associated with the slave device 106). For example, the master device 104 can generate one or more register data requests that can be received by the slave CSR component 302. Additionally, the slave CSR component 302 can send (e.g. forward) the one or more register data requests to the slave register(s) 304. Additionally, the slave CSR component 302 can send (e.g., forward) one or more register data responses received from the slave register(s) 304. For example, the slave CSR component 302 can send (e.g., forward) one or more register data responses to the master device 104.

[0041] In an aspect, the slave CSR component 302 can send a proxy register data response to the master device 104 in response to a determination that the master device 104 has not received a register data response associated with the register data request from the register(s) 304 within a predetermined time period. In an aspect, the predetermined time period can be programmable and/or configurable. In one example, a value of the

predetermined period of time can be determined based on information associated with the slave device 106 and/or the slave register(s) 304. As such, the predetermined period of time can be varied based on a particular implementation of the slave device 106 and/or the slave register(s) 304. A value of the predetermined period of time can be determined based on information associated with the master device 104. A predetermined period of time for a particular master device 104 can be different than a predetermined period of time for another master device 104 (e.g., a predetermined time period associated with a register data request can be uniquely determined). In an aspect, a clock counter associated with the register data request can be maintained by the timer component 10 and/or the slave CSR component 302. Additionally, the timer component 110 and/or the slave CSR component 302 can generate a CSR timeout signal in response to a determination that a threshold level associated with the clock counter is reached before receiving a register data response associated with the register data request. The slave CSR component 302 can be configured for sending a proxy register data response to the master device 104 in response to generating and/or receiving the CSR timeout signal.

[0042] In an aspect, the slave CSR component 302 can send and/or receive one or more register data transactions associated with the slave register(s) 304 after a timeout signal associated with the slave device 106 is received from the timeout component 1 0. As such, register data transactions associated with the slave register(s) 304 can continue after a slave device 106 is determined to be unresponsive.

[0043] In another aspect, the clock counter implemented by the timeout component 110 can be triggered by a signal (e.g., a periodic 'tick' signal) generated by the slave CSR component 302 and/or the slave register(s) 304. For example, the clock counter implemented by the timeout component 110 (e.g., a timeout field associated with the data request) can be incremented based on the signal generated by the slave CSR component 302 and/or the slave register(s) 304. In an aspect, a threshold level associated with the clock counter can be associated with a hexadecimal value (e.g., OxFF). However, the threshold value can be associated with a different type of value. The clock counter implemented by the timeout component 110 (e.g., a timeout field associated with the data request) can be incremented by a single hexadecimal value based on the signal generated by the slave CSR component 302 and/or the slave register(s) 304. In another aspect, the signal generated by the slave CSR component 302 and/or the slave register(s) 304 can be implemented by a clock counter for each pending data request. For example, a clock counter for each pending data request can be updated based on the signal generated by the slave CSR component 302 and/or the slave registers) 304.

[0044] FIG. 4 depicts a block diagram illustrating an embodiment of a system 400. System 400 includes the slave shim interconnect 102, the at least one master device 104, the slave device 106, a slave interface 402 and a slave interface 404. In an aspect, the slave interface 402 can be implemented as a bus-side slave interface. In another aspect, the slave interface 404 can be implemented as a device-side slave interface.

[0045] The slave interface 402 can be implemented between the at least one master device 104 and the slave shim interconnect 102. For example, the slave interface 402 can receive data requests from the at least one master device 104 and/or send data responses to the at least one master device 104 via the bus 112. The slave shim interconnect 102 can be implemented between the slave interface 402 and the slave interface 404. The slave interface 404 can be implemented between the slave shim interconnect 102 and the slave device 106. In an aspect, the slave interface 402 and/or the slave interface 404 can be an AXI slave interface.

[0046] In an aspect, the slave interface 402 and/or the slave interface 404 can be configured to receive and/or store incoming data requests while outgoing data responses are being processed. For example, the slave interface 402 and/or the slave interface 404 can implement and/or be associated with one or more FIFO memories to receive and/or store incoming data request while outgoing data responses are being processed. In one example, the slave interface 402 and/or the slave interface 404 can implement data flow control (e.g. data request and/or data response flow control) in response to the one or more FIFO memories being full. In another aspect, the slave interface 402 and/or the slave interface 404 can be configured to receive and/or store outgoing data responses while incoming data requests are being processed. For example, the slave interface 402 and/or the slave interface 404 can implement and/or be associated with a FIFO memory (e.g., a different FIFO memory) to receive and/or store outgoing data responses while incoming data requests are being processed. In an aspect, the slave interface 404 can be disabled in response to a timeout signal associated with the slave device 106 being generated.

[0047] FIG. 5 is a block diagram illustrating an embodiment of a system 500. System 500 includes the slave shim interconnect 102. The slave shim interconnect 102 can include at least the interface component 108, the timeout component 110 and the slave CSR component 302. The interface component 108 can include the transaction ID component 202 and/or the order component 204.

[0048] The slave shim interconnect 102 can be coupled to the at least one master device 104 and/or the slave device 106. For example, the interface component 108 can receive a write (wr) address channel signal, a write data channel signal and/or a read (rd) address channel signal from the at least one master device 104. The interface component 108 can send a write response channel signal and/or a read data channel signal to the at least one master device 104. The interface component 108 can send a write address channel signal, a write data channel signal and/or a read address channel signal to the slave device 106. The interface component 108 can receive a write response channel signal and/or a read data/response channel signal from the slave device 106. The slave CSR component 302 can send a CSR address/control signal, a CSR write data signal and/or a master shim select signal. The slave CSR component 302 can receive a CSR read data signal and/or a CSR acknowledgment signal. The timeout component 110 can generate a slave device timeout signal. The slave CSR component 302 can generate a slave CSR timeout signal.

[0049] In an aspect, signals can be received from the at least one master device 104 via a bus-side slave interface 502 (e.g., the slave interface 402) and/or sent to the at least one master device 104 via the bus-side slave interface 502 (e.g., the slave interface 402). In another aspect, signals can be received from the slave device 106 via a device-side slave interface 504 (e.g., the interface 404) and/or sent to the slave device 106 via the device-side slave interface 504 (e.g., the interface 404). In another aspect, signals can be received from the slave register(s) 302 via a CSR slave interface 506 and/or sent to the slave register(s) 302 via the CSR slave interface 506. The interface component 108 can be configured to manage data transactions (e.g., signals) associated with the bus-side slave interface 502 and/or the device-side slave interface 504, as more fully disclosed herein. Furthermore, the slave CSR component 302 can be configured to manage register data transactions (e.g., signals) associated with the CSR interface 506, as more fully disclosed herein

[0050J Methods that may be implemented in accordance with the described subject matter may be better appreciated with reference to the flow charts of FIGs. 6-11. While for purposes of simplicity of explanation, the methods are shown and described as a series of blocks, it is to be understood that the claimed subject matter is not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the methods described hereinafter. [0051] FIG. 6 is a flow diagram of an embodiment of a method for generating a timeout signal based on a clock counter associated with a data request. Method 600 can begin at block 602, where a data request is received from a master device (e.g., by an interface component 08). In one example, a write request can be received from a master device. In another example, a read request can be received from a master device. In an aspect, the data request can be received as a single data request from the master device. In another aspect, the data request can be included in a group of data requests received from the master device.

[0052] At block 604, the data request is forwarded (e.g., by an interface component 108) to a slave device. For example, the data request received by the master device can be sent to the slave device.

[0053] At block 606, a clock counter associated with the data request is maintained (e.g., by a timeout component 110). For example, a clock counter (e.g., a timer) associated with the data request can be generated, configured and/or maintained in response to receiving the data request from the master device and/or forwarding the data request to the slave device.

[0054] At block 608, a timeout signal is generated (e.g., by a timeout component 110) in response to a determination that a threshold level associated with the clock counter is reached before receiving a data response associated with the data request from the slave device. For example, a timeout signal can be generated in response to a determination that a predetermined period of time has passed since the data request was forwarded to the slave device (e.g., without receiving a data response from the slave device within the predetermined period of time).

[0055] FIG. 7 is a flow diagram of an embodiment of a method for implementing data transactions in connection with a slave shim interconnect. Method 700 can begin at block 702, where a data request is received (e.g., by an interface component 108) from a master device. At block 704, the data request is forwarded (e.g., by an interface component 108) to a slave device. At block 706, a clock counter associated with the data request is maintained (e.g., by a timeout component 110).

[0056] At block 708, a proxy data response is sent (e.g., by an interface component 108) to the master device in response to a determination that a threshold level associated with the clock counter is reached. For example, a proxy data response can be sent to the master device in response to a determination that a predetermined period of time has passed since the data request is forwarded to the slave device. In an aspect, the proxy data response can be sent to the master device in response to receiving a timeout signal associated with the data request (e.g., a timeout signal associated with the data request being generated).

[0057] At block 710, a data response is forwarded (e.g., by an interface component 108) to the master device in response to receiving the data response from the slave device before the threshold level associated with the clock counter is reached. For example, a data response generated by the slave device can be forwarded to the master device in response to receiving the data response within the predetermined period of time. In an aspect, the data response generated by the slave device can be forwarded to the master device in response to a determination that a timeout signal associated with the data request has not been generated and/or received.

[0058] FIG. 8 is a flow diagram of another embodiment of a method for implementing data transactions in a slave shim interconnect. Method 800 can begin at block 802, where a data request is received (e.g., by a slave shim interconnect 102) from a master device. At block 804, the data request is sent (e.g., by a slave shim interconnect 102) to a slave device. At block 806, a data response associated with the data request is forwarded (e.g., by a slave shim interconnect 02) to the master device in response to receiving the data response from a slave device and a determination that a predetermined period of time has not passed since sending the data request to a slave device. For example, a data response associated with the data request can be forwarded to the master device in response to receiving the data response from a slave device before a clock counter associated with the data request reaches a predetermined threshold value and/or a timeout signal associated with the data request is generated. At block 808, a proxy data response associated with the data request is sent (e.g., by a slave shim interconnect 102) to the master device in response to a determination that the predetermined period of time has passed since sending the data request to the slave device and the data response associated with the data request is not received from the slave device. For example, a proxy data response associated with the data request can be sent to the master device in response to not receiving the data response from a slave device before a clock counter associated with the data request reaches a predetermined threshold value and/or a timeout signal associated with the data request is generated.

[0059] FIG. 9 is a flow diagram of another embodiment of a method for implementing data transactions in a slave shim interconnect. Method 900 can begin at block 902, where a data request is received (e.g., by an interface component 108). For example, the data request can be received from a master device. In one example, a write request can be received from a master device. In another example, a read request can be received from a master device. In an aspect, the data request can be received as a single data request from the master device. In another aspect, the data request can be included in a group of data requests received from the master device.

[0060] At block 904, a transaction ID entry associated with the data request is stored (e.g., by an interface component 108 and/or a transaction ID component 202). For example, the transaction ID entry associated with the data request can be stored in a linked list data structure. In an aspect, the linked list data structure can be associated with at least one FIFO memory.

[0061] At block 906, the data request is forwarded (e.g., by an interface component 108) to a device. For example, the data request can be forwarded to a slave device.

[0062] At block 908, it is determined (e.g., by a timeout component 110) whether a predetermined time period has passed since forwarding the data request. For example, it can be determined whether a clock counter associated with the data request (e.g., started in response to forwarding the data request) has reached a predetermined threshold level.

[0063] If no, method proceeds to block 910. If yes, method 900 proceeds to block 916. At block 910, it is determined whether a data response has been received (e.g., by an interface component 108 and/or an order component 204). For example, it can be determined whether a data response associated with the data request has been received from the device (e.g., the slave device). If yes, method 900 proceeds to block 912. If no, method 900 returns to block 908. At block 912, the data response is forwarded (e.g., by an interface component 108 and/or an order component 204). For example, the data response received from the device (e.g., the slave device) can be forwarded to another device (e.g., the master device). At block 914, the transaction ID entry is deleted (e.g., by an interface component 108 and/or an order component 204). For example, the transaction ID entry associated with the data request can be deleted. In one example, the linked list data structure can be updated to account for the forwarding of the data response associated with the data request. After block 914, method 900 can end.

[0064] At block 916, a proxy data response associated with the data request is sent (e.g., by an interface component 108 and/or an order component 204). For example, a proxy data response can be sent on behalf of the device (e.g., the slave device).

[0065] At block 918, the transaction ID entry is deleted (e.g., by an interface component 108 and/or an order component 204). For example, the transaction ID entry associated with the data request can be deleted. In one example, the linked list data structure can be updated to account for the sending of the proxy data response associated with the data request.

[0066] At block 920, other data requests are managed and/or other proxy data responses are sent on behalf of the device (e.g., by an interface

component 08 and/or an order component 204). For example, proxy data responses can be sent to other devices (e.g., one or more master devices) for future data requests associated with the device (e.g., the slave device).

[0067] FIG. 10 is a flow diagram of an embodiment of a method for processing a data request is shown. Method 1000 can begin at block 1002, where a data request is received (e.g., by a slave shim interconnect 102). For example, a data request can be received from a master device.

[0068] At block 1004, a transaction identification (ID) is extracted from the data request (e.g., by a slave shim interconnect 102). For example, a transaction ID associated with the data request can be determined.

[0069] At block 1006, data storage is allocated based on the transaction ID (e.g., by a slave shim interconnect 102). In one example, the data storage can be associated with a linked list data structure. In another example, the data storage can be associated with a FIFO memory. [0070] At block 1008, it is determined (e.g., by a slave shim interconnect 102) whether a data transaction associated with the transaction ID is waiting for a response. For example, it can be determined whether the transaction ID (e.g., an entry associated with the transaction ID) is already stored in the data storage for a previous data request.

[0071] If no, method 1000 proceeds to block 1010. At block 1010, the data structure is formatted (e.g., by a slave shim interconnect 102) for a new transaction ID. For example, the data structure can be formatted to account for the transaction ID being a new transaction ID (e.g., a transaction ID that is not already stored in the data storage). At block 1012, information associated with the data request and/or the transaction ID is stored in an initial entry in the data structure for the transaction ID (e.g., by a slave shim interconnect 102). For example, information associated with the data request and/or the transaction ID can be stored in an initial entry for a new data list (e.g., a new data list of a linked list data structure) associated with the transaction ID. After block 012, methodology 1000 can end.

[0072] If yes, method 1000 proceeds to block 1014. At block 1014, formatting of the data structure is updated (e.g., by a slave shim interconnect 102) to account for the data request associated with the transaction ID. For example, an entry for the linked list data structure (e.g., an entry associated with the transaction ID) can be updated so that the data request is associated with other data requests related to the transaction ID (e.g., other data requests associated with the transaction ID that are already stored in the data storage). In an aspect, an order for processing data requests associated with the transaction ID can be updated to account for the data request. At block 0 6, information associated with the data request and/or the transaction ID is stored in the data structure (e.g., by a slave shim interconnect 102). For example, information associated with the data request and/or the transaction ID can be stored in a new entry for a data list (e.g., a data list of a linked list data structure) associated with the transaction ID. After block 1016, methodology 1000 can end.

[0073] FIG. 11 is a flow diagram of an embodiment of a method for processing a data response. Method 1100 can begin at block 1102, where a data response is received (e.g., by a slave shim interconnect 102). In example, the data response can be received from a slave device. In another example, the data response can be a proxy data response generated by a slave shim interconnect.

[0074] At block 1104, a transaction ID is extracted from the data response (e.g., by a slave shim interconnect 102). For example, a transaction ID associated with the data response can be determined.

[0075] At block 1106, it is determined (e.g., by a slave shim interconnect 102) whether the transaction ID is stored in a data structure. For example, it can be determined whether an entry for a data request associated with the transaction ID is stored in the data structure (e.g., whether a data request associated with the transaction ID has been received).

[0076] If no, method 1100 proceeds to block 1108. At block 1108, an error message is generated and/or error information is determined (e.g., by a slave shim interconnect 102). For example, an error message associated with the data response can be generated and/or error information associated with the data response can be determined. After block 1108, method 1100 can end.

[0077] If yes, method 1100 proceeds to block 1110. At block 1110, the transaction ID and/or information associated with the transaction ID is obtained from the data structure (e.g., by a slave shim interconnect 102). For example, an entry for the transaction ID can be found in the data structure. Furthermore, information associated with the transaction ID and/or a data request associated with the data response can be obtained.

[0078] At block 1112, it is determined (e.g., by a slave shim interconnect 102) whether the transaction ID is associated with a single data request. For example, it can be determined whether only one entry for the transaction ID is stored in the data structure.

[0079] If no, method 1100 proceeds to block 1114. At block 1114, information associated with the transaction ID is updated in the data structure (e.g., by a slave shim interconnect 102). For example, an entry in a data list associated with the transaction ID (e.g., a data list in a linked list structure) can be deleted. After block 1114, method 1100 can proceed to block 1118.

[0080] If yes, method 1100 proceeds to block 1116. At block 1116, information associated with the transaction ID is removed from the data structure (e.g., by a slave shim interconnect 102). For example, a data list associated with the transaction ID (e.g., a data list in a linked list structure) can be deleted. After block 1116, method 1100 can proceed to block 11 18.

[0081] At block 1118, information associated with the transaction ID is inserted into the data response (e.g., by a slave shim interconnect 102). For example, the transaction ID and/or other information associated with the transaction ID can be appended to the data response.

[0082] At block 1 120, the data response is forwarded (e.g., by a slave shim interconnect 102). For example, the data response can be forwarded to a master device that transmitted a data request associated with the data response.

[0083] The techniques described herein can be applied to any device where it is desirable to generate a timeout signal based on a clock counter associated with a data request. Handheld, portable and other computing devices and computing objects of all kinds can be used in connection with the various embodiments, i.e., anywhere that a device may wish to generate a timeout signal based on a clock counter associated with a data request.

Accordingly, the below general purpose remote computer described below in FIG. 12 is but one example, and the disclosed subject matter can be

implemented with any client having network/bus interoperability and interaction.

[0084] FIG. 12 illustrates an example of a computing system environment 1200 in which some aspects of the disclosed subject matter can be

implemented, the computing system environment 1200 is only one example of a suitable computing environment for a device and is not intended to suggest any limitation as to the scope of use or functionality of the disclosed subject matter.

[0085] FIG. 12 is an exemplary device for implementing the disclosed subject matter includes a general-purpose computing device in the form of a computer 1210. Components of computer 1210 may include a processing unit 1220, a system memory 1230, and a system bus 1221 that couples various system components including the system memory to the processing unit 1220.

[0086] Computer 210 includes a variety of computer readable media. By way of example, computer readable media can comprise computer storage media and communication media. The system memory 1230 may include computer storage media in the form of volatile and/or nonvolatile memory. [0087] FIG. 13 is a schematic diagram of an exemplary networked or distributed computing environment. The distributed computing environment comprises computing objects 1310, 1312, etc. and computing objects or devices 1320, 1322, 1324, 1326, 1328, etc., which may include programs, methods, data stores, programmable logic, etc., as represented by applications 1330, 1332, 1334, 1336, 1338 and data store(s) 1340.

[0088] In a network environment in which the communications network 1342 or bus is the Internet, for example, the computing objects 1310, 1312, etc. can be Web servers with which other computing objects or devices 1320, 1322, 1324, 1326, 1328, etc. communicate via any of a number of known protocols, such as the hypertext transfer protocol (HTTP).

[0089] The disclosed subject matter can be implemented as a method, apparatus, or article of manufacture using typical manufacturing, programming or engineering techniques to produce hardware, firmware, software, or any suitable combination thereof to control an electronic device to implement the disclosed subject matter. Computer-readable media can include hardware media, software media, non-transitory media, or transport media.