Event-driven read system with non-priority arbitration for multi-channel data sources - Patents.com

Abstract

The event-driven read management system includes non-priority access arbitration of a plurality of channels. The system includes an arbitration tree circuit, a response circuit, an in-channel logic circuit, and an output periphery circuit. The arbitration tree circuit determines which of the plurality of channels to grant access to a common signaling resource shared by the plurality of channels based on a read access request provided by at least one of the plurality of channels. The arbitration tree circuit terminates a previous read transaction and initiates a subsequent read transaction in response to a single edge of a clock signal. The in-channel logic circuit terminates a previous read transaction and initiates a subsequent read transaction in response to receiving an acknowledge token. The output periphery circuit converts information received from the plurality of channels to an output format on the common signaling resource.

Description

[Technical Field]

[0001] Government License Rights Statement This invention was made with government support under Contract No. DE-SC0012704 awarded by the U.S. Department of Energy. This invention was made with government support under NASA grant NNX16AC42G awarded by the National Aeronautics and Space Administration. The U.S. Government may have certain rights in this invention.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application is an international application claiming the benefit of and priority to U.S. Provisional Application No. 63 / 175,625, filed April 16, 2021, and U.S. Provisional Application No. 63 / 244,692, filed September 15, 2021, the disclosures of which are incorporated herein by reference in their entireties. [Background technology]

[0003] background The disclosed embodiments generally relate to an event-driven read system with non-priority arbitration for multi-channel data sources. Summary of the Invention [Problem to be solved by the invention]

[0004] overview The disclosed embodiment relates to an event-driven read management system including non-priority access arbitration for multiple channels. The system includes an arbitration tree circuit, a response circuit, an in-channel logic circuit, and an output peripheral circuit. The arbitration tree circuit determines which of the multiple channels to grant access to a common signaling resource shared by the multiple channels based on a read access request provided by at least one of the multiple channels. The arbitration tree circuit eliminates simultaneous occurrences of multiple read access requests from the determination, and the read access request is stored in the arbitration tree circuit until access to the common signaling resource is granted by the arbitration tree circuit. The arbitration tree circuit terminates a previous read transaction and initiates a subsequent read transaction in response to a single edge of a clock signal. The response circuit is operably connected to the arbitration tree circuit, and the state of the clock signal represents an acknowledge token. The acknowledge token is provided to the arbitration tree circuit, and the arbitration tree circuit uses the acknowledge token to grant access to the common signaling resource. The in-channel logic circuit is operatively coupled to the arbitration tree circuit and generates read access requests and receives acknowledge tokens. In response to receiving the acknowledge token, the in-channel logic circuit terminates a previous read transaction and initiates a subsequent read transaction. The output peripheral circuit converts information received from the multiple channels into an output format for a common signaling resource.

[0005] The common signaling resource may include at least one of an analog signaling line and a digital signaling line, and the read access request may be generated in response to an event, the event may include activation of at least one of the multiple channels to generate transmissible data. The read transaction may include multiple read phases, at least one of which may result in the transmission of at least a portion of information from one of the multiple channels to the common signaling resource. A duty cycle associated with the clock signal may be selectable to maximize settling time in relation to the common signaling resource, and the determining may include determining which of the multiple read phases associated with the read transaction are assigned to the multiple channels independently of at least one of the read access requests stored in the arbitration tree circuit, the received read access request, and the relative positions of the multiple channels with respect to the arbitration tree circuit. The amount of edges associated with the clock signal may be equal to the amount of read phases associated with the read transaction, and the arbitration tree circuit may operate asynchronously with the multiple channels. The arbitration tree circuitry may operate synchronously with the output peripheral circuitry, and may operate synchronously with the in-channel logic circuitry, which may operate asynchronously in generating read access requests using the acknowledge token such that the duration of the acknowledge token defines an acceptance time window associated with the read access request.

[0006] The duty cycle of the acknowledge token signal may be selectable to extend the minimum read phase time. Multiple channels may contribute information to a common signaling resource such that the transmission order associated with simultaneously requesting channels is independent of the arbitration tree position associated with the simultaneously requesting channels. If an arbitration cell arbitrates not only between read requests but also between read requests and the state of the acknowledge line, the read request output at each stage of the arbitration tree may represent the logical OR of request signals from stages lower in the arbitration tree, or the logical OR of the resulting signals from arbitration between requests or internal signals of a single arbitration cell. Thus, the acknowledge token is prevented from being blocked even if there are still active read access requests when the read is completed.

[0007] The disclosed embodiments further relate to a method for non-priority arbitration of multiple channels using an event-driven read management system, the method including using an arbitration tree circuit to determine which of the multiple channels to grant access to a common signaling resource shared by the multiple channels, the determination being based on a read access request provided by at least one of the multiple channels, the method including using the arbitration tree circuit to exclude concurrent occurrences of multiple read access requests from the determination, the method including storing the read access requests in the arbitration tree circuit until access to the common signaling resource is granted by the arbitration tree circuit, the method including using the arbitration tree circuit to terminate a previous read transaction and initiate a subsequent read transaction in response to a single edge of a clock signal, the method including: The method includes providing an acknowledge token to an arbitration tree circuit, the arbitration tree circuit using the acknowledge token to grant access to the common signaling resource, the state of a clock signal representing the acknowledge token; the method includes using an in-channel logic circuit to generate a read access request and receive the acknowledge token, the in-channel logic circuit being operably coupled to the arbitration tree circuit; the method includes using the in-channel logic circuit to terminate a previous read transaction and initiate a subsequent read transaction in response to receiving the acknowledge token; and the method includes using an output periphery circuit to convert information received from the multiple channels into an output format for the common signaling resource.

[0008] The disclosed embodiments further include a computer-readable medium including instructions that, when executed by a processing device, perform operations including: determining, using an arbitration tree circuit, which of a plurality of channels to grant access to a common signaling resource shared by the plurality of channels, the determination based on a read access request provided by at least one of the plurality of channels; using the arbitration tree circuit to exclude from the determination multiple concurrent read access requests; storing the read access requests in the arbitration tree circuit until access to the common signaling resource is granted by the arbitration tree circuit; and using the arbitration tree circuit to terminate a previous read transaction and initiate a subsequent read transaction in response to a single edge of a clock signal. the operations include initiating a read access request using an in-channel logic circuit and receiving the acknowledge token, the in-channel logic circuit being operably coupled to the arbitration tree circuit, the operations including terminating a previous read transaction and initiating a subsequent read transaction in response to receiving the acknowledge token, and the operations including using an output periphery circuit to convert information received from the multiple channels into an output format for the common signaling resource. [Means for solving the problem]

[0009] Other embodiments will become apparent from the following detailed description considered in conjunction with the accompanying drawings, which should be understood, however, that the drawings are designed as an illustration only, and not as a definition of the limits of any of the embodiments.

[0010] The following drawings are provided by way of example only, and not by way of limitation, and like reference numerals (where used) refer to corresponding elements throughout the several drawings. [Brief explanation of the drawings]

[0011] [Figure 1] 1 illustrates a read resource management system having multiple sources of data requesting reads asynchronously, where the common output bandwidth is significantly less than the total bandwidth of the channels during simultaneous channel submissions. [Figure 2A] FIG. 1 is a block diagram of a data-push architecture. [Figure 2B] FIG. 1 is a block diagram of a two-dimensional data-push architecture. [Figure 3] FIG. 1 is a block diagram of a token ring architecture. [Figure 4A] FIG. 1 is a block diagram of a read system having an address-encoder and reset-decoder architecture. [Figure 4B] FIG. 1 is a block diagram of a read system having an address-encoder and reset-decoder architecture and an additional data bus. [Figure 5] FIG. 1 is a block diagram illustrating communication based on an address event representation architecture. [Figure 6] FIG. 1 is a block diagram of an embodiment of a read management system. [Figure 7] FIG. 2 is a block diagram of a first embodiment of an asynchronous read requester. [Figure 8] FIG. 10 is a schematic diagram of a second embodiment of a read requester. [Figure 9A]FIG. 10 is a schematic diagram of a third embodiment of a read requestor having different logic states. [Figure 9B] FIG. 10 is a schematic diagram of a third embodiment of a read requestor having additional signals indicating activity in the channel read phase. [Figure 10A] FIG. 10 is a schematic diagram of a fourth embodiment of a read requester. [Figure 10B] FIG. 10 is a schematic diagram of a fifth embodiment of a read requester. [Figure 11] FIG. 10 is a timing diagram illustrating read requester waveforms. [Figure 12] FIG. 1 is a block diagram of an embodiment of a synchronous read requester. [Figure 13] FIG. 13 is a schematic diagram of an embodiment of a synchronous read requestor shown in FIG. 12. [Figure 14A] FIG. 2 is a block diagram of an embodiment of an arbitration cell. [Figure 14B] 14B is a block diagram of an embodiment of the arbitration cell shown in FIG. 14A of type 0, referred to herein as "arbitration cell type 0." [Figure 14C] 1 is a block diagram of an embodiment of an arbitration cell referred to herein as an "arbitration cell type I." [Figure 14D] FIG. 2 is a block diagram of an embodiment of an arbitration cell referred to herein as an "arbitration cell type II." [Figure 14E] FIG. 2 is a block diagram of an embodiment of an arbitration cell referred to herein as an "arbitration cell type III." [Figure 15] FIG. 2 is a block diagram of an embodiment of an address encoder. [Figure 16A] FIG. 10 illustrates symbols representing arbitration cells depending on the type of arbitration cell and the inclusion of an address encoder. [Figure 16B]FIG. 10 illustrates symbols representing arbitration cells depending on the type of arbitration cell and the inclusion of an address encoder. [Figure 16C] FIG. 10 illustrates symbols representing arbitration cells depending on the type of arbitration cell and the inclusion of an address encoder. [Figure 16D] FIG. 10 illustrates symbols representing arbitration cells depending on the type of arbitration cell and the inclusion of an address encoder. [Figure 17A] FIG. 10 is a block diagram of an alternate configuration of P-type stage and N-type stage arbitration cells. [Figure 17B] FIG. 10 is a block diagram of an alternate configuration of P-type stage and N-type stage arbitration cells. [Figure 18] FIG. 1 is a block diagram of an embodiment of an arbitration tree with an address encoder. [Figure 19A] FIG. 1 illustrates a Seitz arbiter. [Figure 19B] FIG. 1 illustrates an embodiment of an arbiter type I. [Figure 19C] FIG. 1 illustrates an embodiment of an Arbiter Type II. [Figure 19D] FIG. 1 illustrates an embodiment of an Arbiter Type III that may be subject to blockage. [Figure 19E] FIG. 1 illustrates an embodiment of an arbiter type III that is immune to blockage. [Figure 20A] FIG. 1 illustrates an SR latch with a NAND gate and its truth table. [Figure 20B] FIG. 1 illustrates an SR latch with a NAND gate and its truth table. [Figure 21A] FIG. 1 illustrates an SR latch with a NOR gate and a truth table. [Figure 21B] FIG. 1 illustrates an SR latch with a NOR gate and a truth table. [Figure 22A] FIG. 1 illustrates a metastable filter implemented using inverters and buffers. [Figure 22B] FIG. 1 illustrates a metastable filter implemented using inverters and buffers. [Figure 22C] FIG. 1 illustrates a metastable filter implemented using inverters and buffers. [Figure 22D] FIG. 1 illustrates a metastable filter implemented using inverters and buffers. [Figure 23A] FIG. 1 illustrates a metastable filter implemented using multiple input NOR and NAND gates. [Figure 23B] FIG. 1 illustrates a metastable filter implemented using multiple input NOR and NAND gates. [Figure 23C] FIG. 1 illustrates a metastable filter implemented using an inverter with hysteresis. [Figure 23D] FIG. 1 illustrates a metastable filter implemented using an inverter with hysteresis. [Figure 23E] FIG. 1 illustrates a metastable filter implemented using an inverter with feedback. [Figure 23F] FIG. 1 illustrates a metastable filter implemented using an inverter with feedback. [Figure 24A] 1 illustrates an embodiment of a commutator and truth table. [Figure 24B] 1 illustrates an embodiment of a commutator and truth table. [Figure 24C] 1 illustrates an embodiment of a commutator and truth table. [Figure 24D] 1 illustrates an embodiment of a commutator and truth table. [Figure 24E] 1 illustrates an embodiment of a commutator and truth table. [Figure 24F] 1 illustrates an embodiment of a commutator and truth table. [Figure 25A] FIG. 1 illustrates an embodiment of an address encoder implemented using a tri-state buffer. [Figure 25B]FIG. 1 illustrates an embodiment of an address encoder implemented using a tri-state buffer. [Figure 26A] FIG. 1 illustrates an embodiment of an address encoder implemented using tri-state inverters. [Figure 26B] FIG. 1 illustrates an embodiment of an address encoder implemented using tri-state inverters. [Figure 27] FIG. 1 illustrates an embodiment of a response circuit with asynchronous generation of an acknowledgement based on an output request state. [Figure 28] FIG. 1 illustrates an embodiment of a response circuit. [Figure 29] FIG. 1 illustrates an embodiment of an output periphery. [Figure 30] FIG. 1 illustrates a first embodiment of a serializer. [Figure 31] 31 is a timing diagram of waveforms illustrating the operation of the first embodiment of the serializer shown in FIG. 30. [Figure 32] FIG. 10 illustrates a second embodiment of a serializer in which no pull-up / pull-down networks are used on the data signals, maximizing settling time. [Figure 33] 33 is a timing diagram of waveforms illustrating the operation of the second embodiment of the serializer shown in FIG. 32. [Figure 34] FIG. 1 illustrates an embodiment including grouped channels and spatially distributed arbitration trees. [Figure 35] FIG. 1 illustrates an embodiment including grouped channels with independent data buses and arbitration trees. [Figure 36] FIG. 10 illustrates an embodiment including an additional buffering stage on the data bus. [Figure 37] FIG. 1 is a block diagram of at least a portion of an example machine in the form of a computing system for executing methods according to one or more embodiments disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

[0012] It should be understood that elements in the figures are shown for simplicity and clarity, and that common but well-understood elements that are useful or necessary in commercially viable embodiments are not shown in order to facilitate a more unobtrusive view of the illustrated embodiments.

[0013] Detailed Description Data retrieval and computer network systems that collect or transmit data attempt to optimally utilize the available bandwidth associated with the link. One category of data transmission involves links that are permanently configured to guarantee a data streaming rate, which leads to a substantial reduction in latency and data loss at the cost of reserving the link even when data is not being transmitted. Another category involves links that are configured upon receiving a transmission request from a data source, or a data source that probes the channel occupancy and determines whether to occupy the link's bandwidth after verifying that the link is not being used by another concurrent source. The latter carries the risk of false detection of idleness associated with data links due to finite channel propagation speeds. This may occur when two or more distant sources begin transmitting after detecting that the channel is empty. However, transmissions from other channels may still not reach the distant sources, allowing these distant sources to detect that they are busy. To handle such situations without losing transmitted data, collision detection mechanisms, such as those used in the 10BASE5 and 10BASE2 Ethernet standards according to IEEE 802.3, are built into network systems. Solving the transmission medium access problem by instructing the source to send a transmission request to a switch or data concentrator and receive an access acknowledgment utilizes a handshaking protocol. Implementing such a protocol introduces latency and therefore inefficiencies in the read system. Setting up a private link to the source of the data or establishing a handshaking protocol is costly and often requires suboptimal allocation of bandwidth, additional hardware, and increased latency.

[0014] Solving how to efficiently collect data from spatially distributed sources presents similar challenges whether it concerns a distributed grid associated with in-field deployed sensors, a computer on a network, a cell in a content-addressable memory, a channel in a neuromorphic chip, or an element in a primary (line) or secondary (pixelated) radiation detector. These facilities or devices generally share the common characteristic of simultaneously reporting data by two or more sources of data, which may be considered asynchronous with respect to clocking associated with the receiver. While synchronizing sources of data using data convergence is possible by distributing a common time base, achieving this goal comes at a greater cost. Additional links for distributing clock signals incur greater power dissipation. Regardless of how sparse data is transmitted, the clock is widely distributed, especially since there is idle time between successive data transmission events.

[0015] As shown in Figure 1, an efficient readout system 10 is disclosed for collecting sparse data originating from multiple sources or channels 11, the channels 11 operating asynchronously. Each channel 11 optimally provides data to a central data acquisition system 13 such that the order of simultaneously transmitting channels 11 is independent of their geographic location. Protocols and hardware architectures are developed for application specific integrated circuits (ASICs) used to read out, for example, one-dimensional or two-dimensional multi-channel radiation sensors, where these sensors may be implemented using, for example, microstrip or pixelated radiation sensors.

[0016] The readout system 10 provides an alternative to token-passing schemes, but does not exhibit the drawbacks of that scheme, such as the deterministic ordering of readout channels and the variable delays in accessing those channels depending on the channel's location at the beginning or end of the token-passing path. The readout system 10 guarantees that no collisions occur and that no channel is starved for time slot allocations to transmit data. That is, there is no situation in which access to the readout resource is unfairly or persistently denied to one or more of the channels. A characteristic of this readout system 10 is that the common output bandwidth 12 of the data link is significantly less than the combined data bandwidth of all channels 11 when transmitting simultaneously.

[0017] Generally, read resource management architectures fall into the following categories:

[0018] (1) Data-push architecture (DPA) is a data-driven architecture that initiates a read cycle of valid data from a channel without receiving an external trigger. DPA can be particularly seen in simple multi-channel applications such as the one shown in FIG. 2A. DPA receives asynchronous data, records the arrival time, and sequences the data on a common bus. These operations are performed as follows: After an event such as particle deposition, a high logic state is set on the hit line corresponding to the channel where the event occurred. This information is then sent to buffer 19 for storage. Buffer 19 generates a channel reset (crst) signal, which resets the analog circuitry in the channel, preparing it to detect a new event. Information from buffer 19 is strobed into FIFO 20 by the system clock; subsequent operations are then synchronous, as represented by line 28, while the asynchronous data line is represented by line 30. The value of counter 18, interpreted as the event timestamp, is simultaneously strobed into its own FIFO 21. FIFOs 20 and 21 reduce the chance of losing data while also reducing the dead time during which a channel does not detect a new event because it is processing a previous event. The oldest information from FIFO 21 is provided to register 23. This data, called the current processed event, can contain information about multiple events if these events occur at the same timestamp. To handle multiple events, a priority encoder, decoder, and single-bit reset function in register 23 are used. The first of these functions finds the active bit in the logic vector, stores the active bit in register 23, and converts the position of the most significant active bit to a binary value. This value is then latched into an additional register (not shown). From there, the value is transmitted by bus control 27 to output peripheral 25, along with a timestamp. From there, the value is transmitted to an external system.The output from register 23 is also decoded into a one-hot code, which is a binary vector with an active bit in one position. This representation of the address is used to clear a bit in register 23 so that the next hit address can be encoded and transmitted. If there are no more active bits, subsequent data is obtained from FIFO 21. Synchronization with system clock 17 is performed within buffer register 19 or FIFOs 20 and 21. DPA can create metastable states, resulting in invalid logic levels due to asynchronous data from the channel changing near the edges of system clock 17. This can result in invalid timestamp assignments and / or data loss. Figure 2B shows a DPA implementation with a two-dimensional input array providing data to read control and row logic block 31. A practical advantage of DPA is that it does not require the continuous distribution of a clock to the channel. However, DPA may have the following disadvantages: (a) Pipeline stages such as buffers, FIFOs and registers cause delays in outputting data; (b) a metastable state caused by using an asynchronous hit signal to trigger a synchronous read and latch synchronous data (e.g., timestamp); (c) The readout is not entirely data-driven for two-dimensional arrays, since channels with valid hit signals are found after the columns are selected; (d) When multiple events occur, the events are handled using fixed priorities that favor some cells over others.

[0019] (2) As shown in FIG. 3, the token ring architecture (TRA) 37 is a read polling architecture. A token is injected into a chain of channels and moved from one cell to another until it reaches a cell containing valid data. A cell with valid data holds the token for a sufficient amount of time to output the data. After the read of this cell is complete, the cell releases the token for further propagation, as shown in FIG. 3. Signal 36 indicates the token's path until it finds a cell with valid data 38. Then, a read begins, and another cell with valid data 41 waits for the next cycle. If the token starts at token logic 39, channels located far from the source of the token may experience a shortage of tokens during times of high event intensity. Alternatively, if the token is moved from a channel after that channel's read, additional strobing is propagated to all channels in the ring. Therefore, the length of the chain is important. This length determines how many total read time slots are available for data settling, since the token requires time to reach its destination. This travel time can be short or long. If the chain is too long, there is a risk of timing errors. Additional clocks can be distributed throughout the channel to strobe the token's advancement to successive cells. However, the presence of additional clocks increases power consumption. In addition, the time allocation to cover the token's travel time to the furthest cell in the chain and the settling time for the data results in suboptimal use of the link bandwidth in this token-passing read architecture.

[0020] (3) Address-Encoder and Reset-Decoder (AERD) 42 is one form of data-driven read architecture shown in FIG. 4A. Reporting which channel contains the data to be read and switching to the next channel for reporting is accomplished using an arbitration tree 44. The arbitration tree 44 is implemented using a cascade of blocks with substantially identical functions. Cascading is used to expand the amount of channels that are arbitrated. There are two types of inputs to the arbitration tree 44. The first type of input includes a channel STATE signal 48 that indicates data present on the channel or an empty channel. The second type of input includes a SELECT signal 56 on the data acquisition side that is decoded as a RESET 50 signal when it reaches the destination channel. The arbitration tree 44 encodes the address of the channel that is allowed to report during the propagation of the STATE signal 48 until the VALID output signal 46 is acquired. The arbitration tree 44 also decodes channels that receive a RESET 50 signal during the propagation of the SELECT signal 56 in the opposite direction, i.e., from the acquisition side to the channel side. The SELECT signal 56 is generated synchronously using the clock signal if the VALID signal 46 is active. A priority encoder and reset decoder in each block of the arbitration tree 44 are used to select the channel with the encoded address and to select which channel the reset signal is sent to in the case of simultaneous notification of multiple channel occupancies and their report preparation. When the SELECT signal 56 reaches the channel and the RESET 50 signal changes state, a read is initiated. After the RESET 50 signal returns to its initial state, communication with the channel is terminated. The STATE flag is then cleared, and the address is no longer available on the address bus 54. This double-edge scheme allows for a dead time before switching to the next channel, which reduces the available time for driving the bus.Timing in the AERD cells can cause undesirable glitches at two or more RESET inputs on the same edge of the SELECT signal, resulting in data loss.

[0021] In a standard data-driven AERD implementation, data corruption can occur if a higher priority channel requests a read while a lower priority channel is performing a read. In this case, an additional strobe signal distributed across the channels is used to latch the state in all channels before the read begins. However, in implementing this feature, the architecture becomes synchronous rather than event-driven.

[0022] Adding extra in-channel logic 45 to the AERD system provides the ability to read additional data from the channel as shown in Figure 4B. This logic 45 drives the data bus in response to a change in the RESET signal. After the RESET signal returns to its initial state, the buffers in the channel are disabled. In effect, the data on the data bus is available simultaneously with the address on the address bus.

[0023] (4) Address Event Representation (AER) 60 is a data-driven architecture based on the asynchronous arbitration tree 60 shown in FIG. 5. This architecture focuses primarily on cell activity, expressed as its address appearing on the data link. Each event in a channel generates a request. In response to this request, an acknowledgement is generated, transmitting the address of the requesting cell. One of the notable features of AER is that the acknowledgement, which enables the output of data from the channel or its address, is automatically generated based on the request. Regardless of the number of channels requesting communication, only one of these channels is active at any given time to avoid collisions on the link. Communication with external systems is not synchronized by a clock and requires a handshaking interface. These features make AER suitable for specific applications and limit its use to more universal acquisition systems.

[0024] The embodiments of the readout system disclosed herein are adapted for efficient transmission of data from multiple data sources, which may be arranged in one-dimensional, two-dimensional, and / or any other format. These embodiments have improvements and features that are advantageous for integrated readout of strip and pixel radiation detectors, as well as for building neuromorphic or other event-driven processing circuits. These embodiments also allow for transmitting additional data beyond the active channel address, providing a reliable mechanism for preventing channel conflicts accessing a common data bus. An interface to a synchronous data acquisition system is also provided. A block diagram of an embodiment of the readout system 70 is shown in FIG. 6. The readout system 70 can be used in a variety of applications with different units within the channels. A universal interface to these functional units is provided to accommodate different sources and types of input data. The universal interface includes the following signals:

[0025] (1) ain 72 represents an analog input in the form of one or more connections to in-channel logic 76, which contains the results of processing from the analog unit of the channel.

[0026] (2) din 74 represents a digital data input in the form of one or more connections to in-channel logic 76, which has a signal input containing the results of processing from the digital units of the channel.

[0027] (3) cfg 78 represents a configuration input in the form of one or more connections that specify the operating mode of in-channel logic 76 .

[0028] (4) rdy80 is a ready flag, which is set after the channel unit finishes processing the data, and then a read request is sent from the channel.

[0029] The external source of clock (clk) 82 originates from the acquisition system or an on-chip clock resource. The output signals include digital (dout) 84 and analog (aout) 100.

[0030] The functional blocks of the readout system 70 include: (1) In-channel read logic 76 is present in all channels. The primary function of the in-channel logic 76 is to issue a request signaling when data from a channel requires a read (e.g., when data is ready after in-channel processing). The read may include any type of individual or combined analog or digital information generated by the channel, such as the read channel's address identifier, the signal's arrival time, the signal's amplitude, and / or any other processing results. Requesting a read is accomplished by activating the req signal 86. After a read request is issued, the in-channel logic 76 waits for an acknowledge token, the arrival of which indicates that use of the data bus 88 has been granted. The acknowledge token is detectable by the in-channel logic 76 as a change on the ack line 90.

[0031] (2) The arbitration tree 92 decides to which channel the acknowledge token is directed. The interface to the in-channel logic 76 is located at the bottom of the tree. At the top of the tree, the rqo signal, which is the logical OR of all channel requests, is available. The acknowledge input acki is also located at the top of the tree. The arbitration tree 92's decision is based on stored information about new read requests and the order in which these requests have already arrived. Depending on the amount of channels in the system and their grouping, the arbitration tree 92 may contain multiple stages, each consisting of multiple two-input (for read requests) arbitration cells. Each arbitration cell monitors information about its inputs and the origin of the request. Subsequent requests wait until the previous request is withdrawn.

[0032] (3) A response circuit 94 generates acki signals and provides these acknowledgements to the arbitration tree 92 for distribution to channels requesting a read. In the subject architecture, an acknowledge indicates that the logic state on the line changes from a default state, which is the state after reset, to an active state. The default state can be thought of as a token with a fixed lifetime that depends on the duty cycle of the input clock clk. When the token is delivered to a channel, an action is triggered. However, token management differs from that in a token ring architecture. In a TRA, a token is injected into a channel chain whose task is to find the first requesting channel. However, in the subject architecture, the token waits at the top of the arbitration tree 92 until a path to the channel is established by the arbitration tree 92. The token is then distributed to the selected channel, or if a path is not available during its lifetime, the token expires.

[0033] (4) Output peripheral 96 is a synchronization block that converts input data from the data bus and address bus into the appropriate output format used by the chip interface and control block for communicating with external acquisition systems. The format may include a continuous stream of bits. The data and address buses may be separate or may be configured as a single bus, with data and / or addresses multiplexed onto this single bus.

[0034] (5) Data bus 88 is shared across the digital lines of the channels, which are driven in an idle state by default using pull-up-pull-down networks. These lines are used to transmit data from the channels to the output peripheral 96. After a read from a selected channel begins, the tri-state buffers in the channel override the data bus idle state set by the pull-up / pull-down networks with data from the tri-state buffers.

[0035] (6) Analog bus 100 is shared across all channel lines and is used to transmit analog values ​​from the channels to the analog processing block (not shown).

[0036] (7) The address bus 98 is shared across the channel digital lines using tri-state buffers in the arbitration tree 92, where the address of the channel with an established acknowledge path is generated. Alternatively, the address of the current read channel is formed and sent on the data bus directly from the channel selected for reading. Note that the address bus is optional.

[0037] (8) The pull-down / pull-up network 102 is used to set a default value on the data bus 88 when none of the tri-state buffers driving the data bus during a read are active, e.g., because no read request has been issued by any channel, or when the requesting channel is waiting for an acknowledge token. The network 102 is implemented using digital buffers or registers connected between the bus lines and one of the power lines. In either case, the buffers placed in the channels are designed to override the logic state set by the network 102. A buffer with a greater drive strength is used to override this logic state.

[0038] The readout system 70 operates according to the following scheme. (1) The channels operate independently and are generally not synchronized. When any of the channels requests use of a shared resource, that channel activates its ready signal. A read request flag in the in-channel logic is then activated. This operation can be completely asynchronous, which means that the read request flag can be set active at any instant regardless of the clock.

[0039] (2) The request is propagated through the arbitration tree 92 through multiple stages to the rqo output 110. During this process, a path for directing an acknowledge signal is established by logic within each arbitration cell. When two read requests arrive at the same arbitration cell, a path for the acknowledge signal is established for only one of the read requests, and this decision is based on the order of arrival of the read requests. This action is called the arbitration process and is performed by a logic block in the arbitration cell that includes a cell called a "Seitz arbiter." If it is difficult to determine this order as a result of substantially simultaneous read request signals, the arbitration decision may be delayed indefinitely. After arbitration is complete, the read request is propagated to the next stage.

[0040] (3) Information regarding the source of requests 104 arising in the arbitration process is obtained from the arbitration tree 92 and, if used, is available for reading on the address bus 98. In variations without an address bus, addresses may be generated within the channel and moved on the data bus.

[0041] (4) Meanwhile, a response circuit, functioning independently of the arbitration process, generates an acknowledge token based on clock signal clk 82. The token is synchronously available at the acknowledge input of arbitration tree 92 and has a fixed duration. The time between tokens represents the minimum guaranteed time for buffers in the channel to drive the data bus and transmit data to output peripheral 96.

[0042] (5) As soon as the read request reaches the top of the arbitration tree 92, the acknowledge path is completed and the token, if available, is distributed again to the requester. If a token is not available, the arbitration tree 92 waits for the generation of a new token.

[0043] (6) When the token arrives at the cell again, the read process begins. All tokens have the same initial duration at the top of the arbitration tree 92, but the duration of a single read from a channel can vary. This occurs because of how the token is generated and how it is moved from one channel that terminates access to the bus to another that gains access to the bus. This time is maximized when a path for the token is already established before the actual token is generated, and minimized when the read request arrives late. In the latter case, the propagation of the read request through the arbitration tree 92 and the establishment of the acknowledge path essentially competes with the expiration of the associated token. However, the cell read logic is more sensitive to events (e.g., the arrival of a token) than the logic level on the acknowledge line, so varying the token duration is not an issue.

[0044] (7) The in-channel logic 76 may be configured to handle at least one read cycle in response to one read request. This process is called a "read phase" because it divides the overall read into successive read phases. In each read phase, different data can be driven onto the data bus. This allows the width of the bus to be reduced or the bus to be reconfigured to read different data sets from the channel. The latter is achieved by various configurations selected using configuration (cfg) bits. The configurations are dynamically selectable during operation.

[0045] (8) The read signal (rdo) in the in-channel logic 76 may be a single bit or a multi-bit logic vector used to distinguish which read phase is active. One-hot encoding is used for this purpose, meaning that only one bit of the rdo logic vector is active at a time. After a request is issued, the first bit of rdo ​​is set upon the arrival of the first token. This bit is then used to enable a bank of tri-state buffers and / or a bank of transmit gates. Instead of using a bank of gates, a multiplexer can be added to select between the data sent to previously activated gates. The next set of data is sent with the next rdo bit set. In this way, different data can be sent from the channel during each read phase.

[0046] (9) During this time, the read request is held so that the acknowledge path to the channel is not disconnected until the final read phase is completed. As a result, each newly generated token is immediately shared further to the same channel. After each token arrives, a new read phase begins. After the final phase is processed, a subsequent token initiates a reset procedure for the in-channel logic, and the request flag is cleared. This process disconnects the path for the acknowledge.

[0047] (10) If there are pending requests from other channels, a new path is established as soon as all necessary arbitration has been performed. A token previously used to reset a channel's in-channel logic 76 can be reused and sent to the new channel if the token is still valid. This feature advantageously prevents wasted time between reads from different channels.

[0048] (11) Pull-up / pull-down transistor network 102 is used to drive data bus 88 and / or address bus 98 to a selected default value when there is no active read on any of the channels. A preferred technique for selecting this default data pattern is to make the default pattern different from any possible actual data. In addition, the default pattern should already provide direct current (DC) balance in case the data is also transmitted serially without DC balancing encoding.

[0049] (12) Regardless of the source of the data on the data bus 88 or address bus 98, the data is latched into the output peripheral 96 by the clock signal clk82. Latching the data synchronizes the readout with the data acquisition system. Data is latched before the generation of each new token or as long as the data is stable, resulting in a new set of latched data for each token. Data can be transmitted serially. The serialization clock is used to generate the readout token by appropriately dividing the serialization clock.

[0050] (13) The division ratio is derived from the number of bits available at one time at the output peripheral 96 on the data bus 88 and address bus 98 and the amount of output serial link to match the serialization speed.

[0051] (14) Analog values, if provided by the channel, are sampled for further processing in an analog output peripheral (e.g., for analog-to-digital conversion) or buffered in preparation for transmission to an external processing system in parallel with the latched digital data.

[0052] Based on the above description, features of the disclosed system include: (1) Compared to DPA, there is no or virtually no risk of metastable states occurring that could corrupt data. Rather than using a system clock to latch asynchronous data as is done in DPA, there is effectively a clock grating structure in the form of arbitration tree 92. This ensures that latching occurs when the data is already stable due to the order of actions being performed.

[0053] (2) There is no or virtually no delay introduced by the pipeline stages. Data stored in a channel has a direct path to the output periphery after being granted use of the shared data bus. The arbitration process is also completely asynchronous, so that signals flowing from stage to stage do not require additional buffering, and the construction of the arbitration tree 92 ensures that the distance, counted as the amount of gates, from the top of the tree 92 to each channel is the same.

[0054] (3) No direct synchronization is performed using distributed clocks in the channel, which saves space and power. Synchronization is based on fixed token durations that are generated synchronously to create a time window for data. The time between the expiration of the previous token and the generation of the subsequent token is used to guarantee sufficient duration to fetch data from the channel. During this time, data settling time is guaranteed and the data is safely latched when the next token is about to be generated.

[0055] (4) There is no polling; read requests are triggered by the registration of an event on the channel, making the system event-driven.

[0056] (5) Variations in the delay time of receiving an acknowledge token over a channel are minimized by the binary tree topology of arbitration tree 92.

[0057] (6) The risk of missing a time slot when at least one channel is requesting a read but default data is being sent is eliminated because the token can wait for the request to be propagated higher up the tree 92. There are rare situations where the request is sent too late relative to the active token, so that the acknowledge token seen by the cell is too short to trigger a read. However, such a situation does not interfere with the operation of the system. The channels wait for the next available token and maintain synchronization by sending default data to the acquisition system.

[0058] (7) Contention between an incoming new read request and an active channel read is eliminated by the arbitration tree 92, which determines which request was first and stores this information. This is a substantial advantage over the AERD architecture, where no memory blocks are allocated for arbitration.

[0059] (8) There is no prioritization since requests are ordered by arrival time to each arbitration tree 92, and only when a request is satisfied will the next request be rerouted down the acknowledge path.

[0060] (9) Once established, the acknowledge path persists until the corresponding request is cleared. This feature, in conjunction with the continuous generation of new tokens, facilitates the read fading circuitry, since multiple tokens can be fed into the channel in response to only one request.

[0061] (10) Because the generation of the token is strictly connected to the acquisition clock, there is no need for additional synchronization, and therefore the system can operate based on a single clock signal, provided, for example, by an external system, and all periods of this clock are used for transmission.

[0062] A read cycle begins at a cell where, following an operation being performed, the ready signal 80 is set. The ready signal 80 is activated and provided to the in-channel logic 76 along with the resulting data (digital 74 and / or analog 72). The read cycle is completed once the data from the channel is latched at the output periphery. A key block in the in-channel logic 76 is the read requestor 112, shown in more detail in FIG. 7.

[0063] The ready (rdy) signal triggers the controller, which then issues a read request 86. This request is held until the done (dne) 122 signal is no longer active. This feature allows multiple acknowledge tokens to be distributed one at a time to the read requester. At the same time, the active (act) 116 flag is set, causing the read phaser 118 to transition from its initial state to its armed state. In this new state, the read phaser 118 is sensitive to changes on the ack line 90. The controller can also be disabled using one of the configuration (cfg) bits. In this case, no request is issued, which effectively blocks reads from the channel. When a token arrives on the channel, the first read phase is initiated by the read phaser 118 setting one of the bits in the read (rdo) vector 108. Each new token arriving at the read requester 112 can shift the active bit in the rdo logic vector 108 by one position until it reaches the position set by configuration. The done flag 120 is then set and the completion indicator block is armed. The read requestor 112 waits for another token to trigger a done signal 122, which is then fed back to the controller 114, deactivating the req signal 86 and the act signal 116. After the reset is cleared, the acknowledge path to the channel is disconnected. In response to the act signal 116 being reset, the read phaser 118 enters an initial state, in which there are no active bits in the read vector 108.

[0064] Typically, the process from receiving the token to disconnecting the acknowledge path is significantly shorter than the token duration, so when the process is finished, the token is still active and can be redistributed to another cell. This allows two actions to occur during the lifetime of a token, neither of which is adversely affected by simultaneous actions.

[0065] Thus, the two functions performed by a read requestor 112 following distribution of an active token to the read requestor 112 include:

[0066] (1) At the beginning of the read phase, an arriving token initiates a new read phase that lasts until a new token appears.

[0067] (2) At reset initiation, no new reads are initiated. The reset operation is performed immediately to allow as much time as possible for the still valid tokens to be redistributed to other requesting channels, if any.

[0068] An embodiment of a read requestor 124 is shown in Figure 8, in which an additional rst signal 91 is used as a global reset signal. An active request is indicated by a high logic state on the req signal 86. The token is active when the logic state of ack 90 is low, and the bit of the rdo signal 108 is active when that bit is low. Since some applications use different active logic states, an alternative embodiment 126 of the read requestor is implemented as shown in Figure 9. In this case, the active logic states for the rqo, ack, and rdo signals are low, high, high, respectively.

[0069] The maximum amount of read phase is adjusted by increasing or decreasing the amount of flip-flops in the chain within read phaser 118. Thus, the amount of flip-flops 130 and gates 132 shown in FIG. 9A can be increased or decreased as shown in FIGS. 10A and 10B. The mode of operation is illustrated using the example waveforms shown in FIG. 11 based on the following assumptions: (1) acki, ack, req and rdo are active when their logic levels are high.

[0070] (2) dne is active when its logic level is low. (3) There are at most two read phases, and the configuration bit cgfl is used to select one of the two phases.

[0071] (4) Two channels are observed. Based on the waveforms shown in Figure 11, the following characteristics are noted: (1) Actions in the channel logic are triggered when an active token arrives at a channel. An active token at the top of the arbitration tree is represented by one of the logic states on the ack line. In the example shown, the active token is in a high state. The arrival of a token at a channel is represented by a state change at the ack input of the channel, and this event triggers actions in the in-channel logic indicated by the series of arrows 1-1A-1B, 2-2A-2B, 3-3A-3B, 3-3D-3E, and 4-4A-4B, shown in FIG. 11 by arrow 131.

[0072] (2) The minimum read phase time is determined based on the ack duty cycle, flip-flop delay and arbitration tree propagation time.

[0073] (3) After the reset condition, the active tokens are redistributed to different channels as indicated by the series of arrows 3-3A-3B-3C-3D-3E shown in FIG. 11 by arrow 131.

[0074] In one or more of the disclosed embodiments, the duty cycle of the acknowledge signal can be selected to maximize the read phase time. As a result, redistribution based on feature (3) above occurs without risk of collisions on the data bus. Conventional architectures require two edges of the acknowledge signal to be provided to the arbitration tree. For example, a channel is selected on the falling edge of the acknowledge signal and disabled on the rising edge. Such behavior of a read system may previously limit the settling time of data on the data bus by the duration of the high state of the acknowledge signal. These implementations also impose further restrictions on the minimum duty cycle of the acknowledge signal, and therefore the ratio of high to low logic states, because the duration of the high state is required to be long enough to perform additional functions.

[0075] From the read requestor block, an additional rda (read any) signal is derived as an output from the first flip-flop in the read phaser, as shown in Figure 9B. The rda signals 135 and 133 are used as indicators that a read from the channel is occurring regardless of which read phase is currently active. The rda signal is essentially the logical OR of all read signals without the need to add additional logic structures.

[0076] The advantages of the disclosed embodiments are further illustrated by the synchronous read requester with distributed clock 130 shown in FIGS. 12 and 13, in which a clk signal 132 is added. The clk signal 132 has the same source as the ack signal from the top of the arbitration tree, but in these embodiments, it is distributed directly to the channels, thereby eliminating the arbitration tree. In this embodiment 130, the acknowledge signal does not have a dual function, meaning that the reset is not initiated by a token; rather, the clk signal 132 is used to initiate the reset phase. In addition, the request signal 134 is set to an edge of the clk signal 132. These modifications synchronize the rdo signal 136 at the top of the arbitration tree with respect to the ack signal. Therefore, the distinction between empty data and valid data can be made based on the rdo signal 136 rather than by using a pull-up / pull-down network. However, clock distribution must be performed, which adds complexity to the routing process and results in greater power consumption. The use of the clk signal 132 as a trigger, rather than a signal with a pre-defined timing relationship, can also result in metastability. This embodiment 130 represents a departure from the event-driven paradigm, as synchronization is performed at the in-channel logic level, which is not the case with the asynchronous read requester described above.

[0077] In addition to the read requestor, the in-channel logic includes transmission gates and / or tri-state buffers used in conjunction with multiplexers. As a result, two techniques for selecting data to drive the data bus are as follows: (1) Uses multiple banks of tri-state buffers / transmission gates, each connected to a data and / or analog bus, with only one or none of the banks active at a given time, and activation is performed using the rdo136 vector bit.

[0078] (2) Use one bank of tri-state buffers / transmit gates and a multiplexer controlled by the rdo vector 136 between the input data from the cells and the buffers that selects the data to be transmitted at a given time.

[0079] After a request signal 134 is activated, the associated request is provided to the arbitration tree, followed by an arbitration process that distributes tokens to the channels. The arbitration tree is implemented using blocks called arbitration cells, as shown in FIG. 14A. Specifically, a simple arbitration cell, referred to herein as "arbitration cell type 0" in FIG. 14B, receives (read) request signals 152, selects one of the request signals, and routes an acknowledge signal 160 arriving at this cell from a cell above it in the arbitration tree, further downstream in the arbitration tree in the direction from which the accepted request came. The routing is performed by essentially gating the acknowledge signal (i.e., acknowledge gating). This results in a continuous path for the acknowledge token from the top of the tree to the bottom of the tree, where the requesting channel is located. Acknowledge gating is performed in a logic block referred to herein as commutator 158 and is performed using grant signals 154 (e.g., gnt0, gnt1) generated within arbitration cells 150. These grant signals are generated by arbiter 156.

[0080] The arbitration cell 150 includes two blocks as follows. (1) The Seitz arbiter 156 determines which of the req (request) signals 152 arrived first and activates the corresponding gnt (grant) signals 154, which are mutually exclusive, i.e., only one of the gnt (grant) signals 154 is active at any one time.

[0081] (2) Commutator 158 establishes a path for the acknowledge token by directing acki (acknowledge) signal 160 to the output ack (acknowledge) signal 162 corresponding to the active gnt signal 154. Commutator 158 also indicates whether any of gnt signals 154 are active, and if so, sends the request to the next arbitration stage by activating rqo (request output) signal 162. For each arbitration cell 150, an address encoder 170 as shown in FIG. 15 can be added to obtain the address of the cell for which the acknowledge path has been established.

[0082] With the arbitration tree structure divided into multiple stages containing multiple arbitration cells, each stage can provide one bit of an address, which is provided by one of the cells in the stage. To meet this requirement, the adr signal 171 drives one line of the address bus using a tri-state buffer. When any of the gnt signals are active, the adr output is enabled, and the value driven depends on which gnt signal is active. When none of the gnt signals are active, the adr output is in a high-impedance state.

[0083] The logic states that are considered active or inactive depend on the physical implementation. To minimize the amount of transistors used during implementation, two types of blocks with different logic polarities are used: P-type 180, 182 and N-type 184, 186, as shown in Figures 16A-16D. Blocks 182, 186 contain address encoders, while blocks 180, 184 do not. A circle at any port indicates that the corresponding signal is considered active when its logic state is low.

[0084] The arbitration tree is configured as a structure containing M = [log2N] stages, where N represents the amount of cells to be read. Each stage contains n(m) = n(m + 1) × 2 arbitration cells, where m ∈ [1, M-M] and n(m) = 1. The amount of transistors is minimized by configuring the stages to use alternating types of arbitration cells, as shown in Figures 17A and 17B. Based on the cell type, two types of stages are used: P-type 200, 206 and N-type 202, 204. The connections between stages 200, 202, 204, and 206 are also shown in Figures 17A and 17B. One advantage of using alternating stage types is that no additional logic is required between stages. Furthermore, it does not matter which stage type is used first; the selection of stage type can be made based on the logic state of other signals in the system. If an address encoder is used, the arbitration tree 210 is configured as shown in FIG.

[0085] The arbitration cell includes an arbiter that determines which of the two (read) request signals will be selected. The arbiter has no priority over which of the two (read) request signals is selected for routing to the output, but only one of the two read request signals is selected. This selection is a function of arrival time; that is, the first request signal received prevails and is therefore selected. Switching from a selected request signal to another request signal is not permitted for the entire length of time the selected request signal is active. When two request signals arrive simultaneously, one of the request signals is selected. This selection is random and does not result in an ambiguous intermediate step at the output of the arbiter. The transition from selecting one request signal does not include any time when both signals are selected or when back-and-forth switching between selected request signals is eliminated.

[0086] The selected request signal generates a corresponding grant signal 154, which then gates the routing of the acknowledge signal. Blocking the acknowledge path prevents activity from being sent to the channel issuing the read request signal. Conversely, unblocking this path allows an acknowledge token to be sent along the acknowledge path, activating or deactivating the channel to start and stop the transmission of data by the channel on the common data bus. The token is active on the acknowledge path with an assigned expiration time. After this expiration time, the acknowledge signal changes its state to inactive again. This function is achieved by using a digital clock to generate the acknowledge signal. This clock contains alternating logic states, i.e., high and low, that repeat at a given frequency. The ratio of the duration of the high and low states is called the duty cycle. The logic state of the digital clock can be related to the activity of the token, and this relationship depends on the blocks used to construct the arbitration tree and their polarity. The duty cycle and frequency of this digital clock signal are selectable or programmable over a wide range or tolerance.

[0087] The simple arbitration cell 150 shown in FIG. 14B utilizes a single Seitz arbiter 156 that can accept a request signal at any time, regardless of the current level of the acknowledge signal. Switching to a read results in a new channel immediately following the current read. For example, if two request signals are activated simultaneously, the Seitz arbiter 156 switches to the second channel after the first request signal is deactivated, corresponding to the completion of the first channel's read. In this situation, the active state of one output of the Seitz arbiter 156 is deactivated and the second output is activated. However, this smooth transition is only possible if the request output from the arbitration cell remains active throughout the entire described process. Otherwise, an undesirable situation may arise in which a cell higher in the arbitration tree identifies a change, even a short change, in the request output line and interprets this change as not being an active request. This results in a disconnection of the acknowledgement path. Under these circumstances, a short event on the acknowledge line may occur, which reaches the second channel and triggers a read even though the acknowledge line changes to an inactive state again. Therefore, the arbitration cell shown in Figure 14B is not suitable for some applications.

[0088] The request signal emanating from the arbitration cell is generated in the commutator 158 logic block as the logical OR of the incoming request signals (i.e., it is activated when at least one of the input request signals is active). The input to this sum can be taken directly from the grant output of the arbiter as shown in FIG. 14C, from the input to the arbitration cell as shown in FIG. 14D, or can be generated by additional logic within the arbiter as shown in FIG. 14E. The apostrophe characters shown in FIGS. 14C and 14E indicate that mixing different commutator and arbiter embodiments may change the functionality of the arbitration cell. Thus, both the commutator and the arbiter are typically configured as matched pairs.

[0089] The core of the arbitration cell includes a Seitz arbiter 220, an embodiment of which is shown in Figure 19A. The Seitz arbiter 220 includes an SR latch 222 and a metastable filter 224. The SR latch 222 is a bistable multivibrator that stores state information. The SR latch 222 includes two inputs (S and R) and two outputs (Q and ~Q). The operating modes are as follows:

[0090] (1) In the idle state, inputs S and R are inactive, and consequently both outputs Q and ~Q are also inactive. Some studies refer to this state as a forbidden state, which applies to standard logic circuits where ~Q is a negated version of Q. However, this is not the case for the subject arbiter.

[0091] (2) During the idle state, when S becomes active, a set operation occurs, which causes the Q output to transition to the active state.

[0092] (3) During the idle state, when R becomes active, a reset action occurs, which causes the ~Q output to transition to the active state.

[0093] (4) In the hold state, both inputs are active, but only one output is active. The active output is related to the most recent set / reset operation.

[0094] Different types of SR latch 222 may be implemented depending on the logic states of the input and output in the idle state. Two of these types can be implemented using two gates with interconnected outputs to the inputs. For example, FIGS. 20A and 20B show an SR latch embodiment 230 and its corresponding truth table using a NAND gate, where the input is low and the output is high during the idle state. FIGS. 21A and 21B show an SR latch embodiment 240 and its corresponding truth table using a NOR gate, where the input is high and the output is low during the idle state.

[0095] Because the input signals to the SR latch in the arbiter are asynchronous, a situation can arise in which both inputs transition to the active state at or near the same time. This situation creates a race condition, and the SR latch must resolve the condition and switch to a hold state with an active output representing the outcome of this arbitration process. The disclosed embodiment of the SR latch performs this process, but it can take an indefinite amount of time, during which both outputs are in a metastable state that is neither a high nor a low logic state. Physically, this process manifests as a voltage level between the logic supply voltage and ground. Metastability in a circuit can lead to errors in operation. Metastability can also propagate to other logic blocks or be erroneously converted to a valid logic state. In an arbitration tree, the latter possibility is undesirable because it violates the mutual exclusivity requirement when both outputs are in the active state and can cause contention on the data bus. For this reason, a metastable filter is implemented after the SR latch 222. This metastability filter 224 does not propagate metastability to other blocks and causes the output of the Seitz arbiter 220 to remain inactive until the arbitration process is complete.

[0096] The implementation of metastable filter 224 differs for NAND and NOR SR latch configurations, but both configurations can use the same amount of transistors. A pair of embodiments of the metastable filter are as follows:

[0097] (1) The standard filter 250, 252, 254, 256 embodiment is shown at the gate and transistor level in Figures 22A-22E and is implemented using two interconnected inverters (between the input and one of the power lines) and a buffer at the output. During the idle state, both outputs are freely connected to the power line corresponding to the inactive state, regardless of the presence of the interconnect. When one of the inputs changes (the SR latch output is the input for the metastable filter), the second input is used as the supply voltage for the active state. When both inputs change, the maximum output voltage cannot be higher than the metastable voltage and is attenuated by the other input, which has a metastable voltage level that cannot fully open the drive transistor. As a result, both filter output voltage levels are lower than the maximum metastable voltage, and these levels are persistently treated as inactive by the successive buffers until the inputs transition from the metastable state to two final opposite states.

[0098] (2) The embodiment of filters 260, 262 shown in Figures 23A and 23B is based on standard logic cells implemented using multi-input NOR / NANDs, which can be effectively viewed as inverters whose transition thresholds are shifted toward the value of one of the supply lines when all inputs are connected together. The shift occurs due to differences in the drive strengths of the transistors that implement the gates for the different states at the output. In contrast to the standard filter described immediately above, there are no damping elements, and mutual exclusion assurance is obtained by checking that the maximum metastable voltage level remains below the toggle level of the skewed inverter. An advantage of this embodiment is that it can be implemented automatically using standard cell libraries with place-and-route tools.

[0099] (3) The filter embodiments shown in Figures 23C and 23D are based on inverters with hysteresis in their transition characteristics. These embodiments follow similar operating principles to those based on multi-input gates, including shifting the inverter's transition threshold. However, rather than operating on transistor drive strength, these embodiments incorporate positive feedback from the output to the input, and therefore require an additional voltage higher than the nominal transition to be used for the output to change its state. Because there is a risk of metastable conditions only when transitioning from an inactive to an active state at the SR latch output, there is no need to switch the feedback in both directions. This second feedback would make the hysteresis loop wider, which is undesirable because it increases the likelihood that both filter outputs will be in the active state as a result of a fluctuation at the input. As a result, the embodiments shown in Figures 23E and 23F, which have active feedback in only one direction, can be used.

[0100] The filters described above include an inverting function, so the output active state is inverted. Based on the arbitration cell logic polarity in different types of arbitration cells, NAND SR latches with P-type metastable filters are used to implement arbitration cell type P 250, 252, 260, and NOR SR latches with N-type metastable filters 254, 256, 262 are used to implement arbitration cell type N.

[0101] The commutator is the next block used to implement the arbitration cell. The function of the commutator is to combine information about activity at the Seitz arbiter outputs into one signal, which is equivalent to generating a logical OR of the signals, and then provided to the next arbitration stage. Based on the signals from the Seitz arbiter, the commutator also generates a logic path for the acki signal. After this path is generated, the state of the acki signal, based on the commutator input, is propagated to one of the ack outputs corresponding to the active arbiter output. If both arbiter outputs are inactive, the state of the acki signal is not propagated. Two complementary embodiments of commutators 270, 280 with corresponding truth tables are shown in Figures 24A-24D. These embodiments use the same amount of transistors and are used in arbitration cell types P and N, respectively. Because both gnt signals should not be active at the same time, states 272, 282 in the corresponding truth tables are forbidden states that should not occur.

[0102] In arbitration cell type I shown in FIG. 14C, the logical OR is not sensitive to the brief phenomenon that occurs when the arbiter cell toggles between its two inputs and when an acknowledgment is expected to be relayed from one cell output to another. This relaying may not occur correctly as a result of the brief moment during which both outputs of the Seitz arbiter are not active while transitioning from one state to another. This is the problem described for arbitration cell type 0.

[0103] Therefore, the input to the logical OR obtained from the input of the Seitz arbiter cell should not have this short-time phenomenon. Gating of the acknowledge signal (i.e., acknowledge gating) and the logical OR of the request signal may be performed using logic circuits including NAND and / or NOR gates, depending on the desired active logic polarity of the signal at the arbitration cell at a given level of the arbitration tree. The active logic polarity determines the voltage level corresponding to the digital value of the signal and can be different for different signals. The logic polarity can be toggled from one stage of the arbitration tree to another stage of the arbitration tree to simplify the logic design, or maintain the logic design, which may require more logic gates.

[0104] Two embodiments of Seitz arbiters and commutators include P-type and N-type. These embodiments are generally implemented to work optimally with both positive and negative active polarities of signals. For ease of understanding and presentation, the embodiments disclosed herein use the terms arbiter, Seitz arbiter, commutator, arbitration cell, OR block, and / or AND block without specifying the polarity of these features. However, the actual implementation of these features as P-type and / or N-type will be understood by those skilled in the art as described herein in light of De Morgan's laws.

[0105] Arbitration cell type 0 can be used in read systems where no new read request signals arrive during the active time of the acknowledge signal transmitted along the arbitration tree. If this condition is not met, using a single Seitz arbiter in the arbitration cell is insufficient for accurate arbitration. An active acknowledge token is defined as a token that propagates along the arbitration tree, gates through all arbitration cells in this propagation route, reaches the channel that requested the data output, and causes either the start or stop of data communication from the requesting channel. Each time an acknowledge token is gated, the arbitration cell in the arbitration tree, and therefore the channel at the end of the route, encounters a transition or edge. A transition essentially causes an action in the channel related to data transmission, such as starting data output, moving from one read phase to another, or ending data output.

[0106] If it is possible to guarantee that all read request signals arrive or are accumulated during the inactive state of the acknowledge signal, the read system can use arbitration cell type 0 for read management at all levels of the arbitration tree. However, if this condition cannot be guaranteed, a simple arbitration cell type 0 can be used at the upper levels of the arbitration tree. This is because arbitration cell type 0 does not propagate its output request further, and arbitration cells positioned below the upper level of the arbitration tree must be different. These lower-level arbitration cells not only must decide which of the two request signals can be serviced, but must also include new read request signals that arrive during the active level of the acknowledge signal in this arbitration. The latter goal creates the need for arbitration between read request signals and acknowledge signals. This leads to the general concept of a read control system with arbitration that can operate without distributing any system clock to the channel. Channels may send read requests asynchronously, and any possible conflicts are resolved at the arbitration tree level regardless of when the read request was sent.

[0107] Furthermore, in the preferred embodiment, there are two options for more complete arbitration that may be utilized. The first option uses an arbiter type I shown in FIG. 19B and a commutator type 0 shown in FIG. 24E, which is a logically equivalent embodiment of the commutator type 0 that is compatible with the arbiter type I. Together, these functions form an arbitration cell type I. The arbiter type I first arbitrates between two request signals, maintaining the result internally, and the winning request signal is arbitrated with an acknowledge signal.

[0108] The second option is implemented as an arbitration cell Type II with an arbiter Type II shown in FIG. 19C or as an arbitration cell Type III with an arbiter Type III shown in FIG. 19D and FIG. 19E. Both types utilize the same commutator Type II shown in FIG. 24, which is a logically equivalent embodiment of the commutator Type II that is compatible with the arbiter Type III. These arbiters, i.e., Types II and III, reverse operation relative to the arbiter Type I, thereby first arbitrating each individual request signal with an acknowledge signal, and then arbitrating the result of these two arbitrations, resulting in a gating signal that allows further unimpeded propagation of the acknowledge signal along the arbitration tree. Both solutions use the same amount of electronic components or additional buffers, effectively enabling reads in the event of accumulated read request signals without dead time. Buffers may be added to handle additional capacitive loads or to provide desired active logic levels, but buffers may generally be considered optional elements and may be added in the standard procedure of digital implementations using timing enclosures.

[0109] The Type II arbitration cell does not encounter any issues that could lead to errors when arbitrating between channels. However, it may experience dead time between reads, which can be measured as skipped acknowledge time slots. This situation can occur when one of the arbitration cells, and consequently the entire arbitration tree, is blocked until the current token expires rather than being able to accept new data being transmitted. This situation also occurs when a second request is sent simultaneously while an acknowledge token is present in the cell due to an earlier request sent to the same cell. Such blocking occurs because the request output is not gated by the acknowledge input, which can be activated even when the entire arbitration process cannot take place within the arbiter. That is, the token remains in the arbitration cell because the next stage is notified that a request from the previous stage in the tree still exists, but the token cannot be used or redirected from one acknowledge output to a second acknowledge output. This is because a path to the second acknowledge output cannot be established, and as a result, there is no active grant signal. The same blocking phenomenon is observed in an arbitration cell Type III based on the Arbiter Type III embodiment shown in Figure 19D.

[0110] The problem of arbitration tree blockage in the Type III arbitration cell is solved by generating a request output as a logical OR of signals after the first stage of arbitration, thereby using so-called "ferred requests" (freq0, freq1), where the request output is active if at least one of the ferred requests is active. By using this technique, the token is not blocked in the arbitration cell and can be removed from the arbitration cell even if a request is sent while the token is still active in the arbitration cell. This allows the token to be moved to another requesting channel without waiting for the token to expire. An embodiment of the Type III arbiter implementing the above technique is shown in Figure 19E.

[0111] The difference between the two versions of the arbitration cell, i.e., Type I versus Type II or III, manifests in how high up the arbitration tree an arbitration tree break in the acknowledge path propagates when switching from serving one channel to serving another. This results in a different order of reading from the channels when the operation of a read tree with the Type I version of the generalized arbitration cell is compared to the operation of a read tree with the Type II or III version of the generalized arbitration cell. For a read tree with a Type I arbitration tree, the break in the acknowledge path occurs up to the top cell even if two adjacent channels that send their read request signals to the arbitration cell are read (i.e., a domino effect). For a read tree with Type II / III arbitration cells, the acknowledge path is broken only up to the next level of the arbitration tree, and one of the two read request signals is active. In the case of two read request signals in the same arbitration cell, the disconnection of the acknowledge path that occurs in the case of a Type II / III circuit does not occur.

[0112] Therefore, the blocking phenomenon and the method for resolving the blocking phenomenon make the arbitration cell type III, including the arbiter embodiment shown in Figure 19E, the preferred arbitration method when the acknowledge path should be disconnected only from the nearest level of the arbitration tree.

[0113] Another element used to implement the arbitration cell is an address encoder. The address encoder is implemented in two complementary embodiments 290, 294 shown in Figures 25A and 25B for use in different arbitration cell types. Alternatively, embodiments 298, 304 having tri-state inverters rather than tri-state buffers can be used, as shown in Figures 26A and 26B.

[0114] Abandoning the priority encoder found in the AERD and AER architectures in favor of a Seitz arbiter is advantageous in read systems because it introduces an asynchronous memory element while eliminating glitches during arbitration and distribution of acknowledgments. An embodiment using a Seitz arbiter that is asynchronous and generates an acknowledge token based on a request is implemented according to a disclosed embodiment using a response circuit 308, such as the one shown in FIG. 27. However, this embodiment 308 cannot generate multiple tokens that can be used by in-channel logic to provide multiple read phases or initiate a request reset. For these reasons, the embodiment of the response circuit 312 shown in FIG. 28 is used. In this embodiment 312, the token is generated based on a clock provided directly by the external acquisition system or derived from the external acquisition system using an on-chip clock management circuit. The decision regarding token injection is not made based on the request; rather, the token is generated when a time window expires synchronously, so the time frame for reading is also precisely defined.

[0115] FIG. 29 shows an embodiment of an output peripheral block 313 including a system serializer 314 and a clock divider 316. An external clock 318 is fed to the clock divider 316 and divided by a factor of M. The original clock 318 and the divided clock 320 are fed to the serializer 314 as a fast clock (fclk) 320 and a slow clock (sclk) 318, respectively. The slow clock 318 is used to latch a parallel on-chip data bus 322 and / or an analog bus 324 (pin), and the fast clock 320 is used to serially transmit the data using a serial output (sout). The slow clock 318 is also fed to the response circuitry as a source of a token. This relationship (i.e., using the same source clock to latch data and activate / deactivate in-channel reads) synchronizes the read process and eliminates potential metastability issues. The amount of serial output lines present and / or used is not limited, and additional serial output lines can be used in parallel to transmit more data simultaneously. In general, the amount of bits latched in the serializer during a read cycle from a channel is equal to the product of the serialization factor and the output amount.

[0116] An embodiment of the serializer 340 is shown in FIG. 30, where the number of flip-flops in the ring counter block 342 and data FF block 344, and the number of buffers in the tri-state buffer block 346, depend on the number of data lines. Generally, both of these numbers are equal unless additional functions, such as serial-to-parallel data transmission, are performed. The clock synchronization block 348 synchronizes the edges of the fast clock 320 and the slow clock 318 to initiate the serialization process. The source selection block is used to send a synchronization pattern to the external acquisition system after reset. This operation is used to define the first bit of a data frame in the output bitstream. The ring counter 342 stores the actual position of the bit to be transmitted. This position is stored as a vector with one active bit at a given time. The ring counter 342 is initialized using the set (S) / reset (R) pins of the flip-flops included in the ring counter 342. The data FF block 344 contains a set of flip-flops used to latch values ​​from the data bus 322. Tri-state buffer 346 drives the serial output line with the bit value corresponding to the location pointed to by ring counter 342 .

[0117] The waveforms shown in Figure 31 illustrate the operations performed by the serializer. These waveforms show the serializer operation cycle following a reset (low level on the rst line) and the cause-effect dependencies between the individual signals. *The data appearing on the bus is provided as an example only and will actually depend on the channel activity. The output of the "synch-SYNCH" value is forced by the active state of the synch_data signal 325. Data from the data bus 322 is latched between the falling edge of the slow clock 318, which corresponds to the last moment before the token expires and the read phase is triggered, and the next rising edge, which corresponds to the end of the read phase or communication with the channel and the start of a new read phase, if necessary. An additional amount of flip-flops, placed at the end of a set of flip-flops using a different trigger source, may be used to ensure that the data is stable when the selected buffer is enabled.

[0118] When there is no active read from any channel, the state of the data bus is set by the pull-up / pull-down network, and this state, called the "default" or "empty" state, is latched in the serializer.

[0119] To save the power required to override the default state of the data bus during a read, another alternative approach is introduced. Rather than using pull-up / pull-down networks on all lines included in the data bus, an additional signal 352 and multiplexer 354 are added, as shown in modified embodiment 350 of FIG. 32. This additional signal 352 is used to indicate that a read from a channel is being performed. A pull-up resistor (not shown) on the additional signal 352 is used, and the high state is overridden during a read by the buffer in the corresponding channel. Based on the state of this additional signal 152, multiplexer 354 selects the source of the data to be processed. This can be either a fixed value representing empty data or data on the data bus driven by a buffer internal to one of the channels from which a read is being performed.

[0120] There is one additional difference between embodiment 350 and embodiment 340. In embodiment 340, data settling time on the data bus is not maximized because data latching occurs at least one fast clock cycle before the rising edge of the slow clock, and the slow clock is responsible for generating the acknowledge token. In contrast, in embodiment 350, settling time is maximized because the rising edge of the slow clock directly latches the data. As a result, a different initialization pattern, including reset and set inputs, for ring counter 342 is used to ensure that bits are transmitted in the correct order, i.e., from least significant bit to most significant bit. In general, latching can occur after the slow clock edge if the data has not been changed.

[0121] The waveforms shown in Figure 33 illustrate the operation of the serializer in embodiment 350. The waveform of the additional selector din[n] 352 depends, for example, on the channel activity. The waveform of the rqo signal from the arbitration tree corresponding to signal din[n] 154 is also shown.

[0122] In a chip or system, arbitration trees are spatially distributed according to a channel configuration, which can be grouped into columns or smaller arrays, for example. Such an embodiment 400 is shown in FIG. 34. One or more outputs used to communicate data outside the chip are used depending on the serialization factor, data bus width, and / or the number of read phases. The number of read phases may be dynamically reconfigured, so that some outputs can be physically present but remain unused in a given configuration. For example, a single-output mode with multiple read phases or a single-phase mode read with multiple outputs can be implemented and configured.

[0123] Managing chips and / or systems containing a larger amount of channels may require additional considerations. Buffers connected to shared lines add extra capacitance to the supplied lines. This capacitance is primarily in the form of buffer output capacitance, but also includes the capacitance of additional wire connections. If the overall capacitance is too large, data may not be able to fully settle on the data bus in the required time, which may result in timing violations and data corruption. Increasing the buffer strength in the channels may be one solution, but this not only consumes additional area and power, but also introduces limitations such as larger buffers with larger output capacitance. Another approach involves dividing the channels into groups, each with its own dedicated data bus. However, this consumes more routing area and may therefore be suitable for systems with narrower buses. Another advantage of this technique is higher data rates because each data bus can be treated as an independent link, allowing multiple channels to be read in parallel during the same time interval. In this case, the overall system can have multiple outputs (i.e., one or more for each group), or high-speed outputs with time division multiplexing. Such an embodiment 402 is shown in Figure 35.

[0124] In general, a combination of both techniques can be implemented in a system by creating a hierarchy of groups. Downstream groups can share one data bus and be bundled in higher upstream groups, with different groups having their own dedicated data bus. It can also be substantially advantageous to introduce additional stages of buffering in each group. These buffers are preferably tri-state buffers that are activated by the logical OR of buffer enable signals associated with the priorities of the lower hierarchies. Such an embodiment 404 is shown in FIG. 36.

[0125] The disclosed embodiments include a well-defined yet flexible architecture. There are no limitations on the type of data that can be transmitted during the readout phase. One of the most useful techniques using the disclosed embodiments is transmitting information from neighboring cells regarding shared events, such as particle hits on the sensor and their associated charge-sharing effects.

[0126] It should be noted that the embodiments disclosed herein may be implemented using MOSFETs or bipolar transistors while remaining within the scope of the intended disclosure.

[0127] One or more embodiments disclosed herein, or portions thereof, may utilize software operating on a computer or workstation. By way of example only and without limitation, FIG. 37 is a block diagram of an embodiment of a machine in the form of a computing system 900, within which resides a set of instructions 902 that, when executed, cause the machine to perform any one or more of the methods according to embodiments of the present invention. In one or more embodiments, the machine operates as a stand-alone device. In one or more other embodiments, the machine is connected to other machines (e.g., via a network 922). In a networked implementation, the machine operates in the capacity of a server or a client user machine in a server-client user network environment. Exemplary implementations of machines as contemplated by embodiments of the present invention include, but are not limited to, a server computer, a client user computer, a personal computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile phone, a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a personal trusted device, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by the machine.

[0128] Computing system 900 includes a processing device 904 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a program memory device 906, and a data memory device 908, which communicate with each other via a bus 910. Computing system 900 further includes a display device 912 (e.g., a liquid crystal display (LCD), a flat panel, a solid-state display, or a cathode ray tube (CRT)). Computing system 900 includes an input device 914 (e.g., a keyboard), a cursor control device 916 (e.g., a mouse), a disk drive unit 918, a signal generation device 920 (e.g., a speaker or remote control), and a network interface device 924, which are operatively coupled with each other and / or with other functional blocks via bus 910.

[0129] The disk drive unit 918 includes a machine-readable medium 926 having stored thereon one or more sets of instructions 902 (e.g., software) that embody any one or more of the methods or functions herein, including those described herein. The instructions 902 may also reside, completely or at least partially, within the program memory device 906, the data memory device 908, and / or the processing device 904 during its execution by the computing system 900. The program memory device 906 and the processing device 904 also constitute machine-readable media. Dedicated hardware implementations, such as, but not limited to, ASICs, programmable logic arrays, and other hardware devices, can similarly be configured to perform the methods described herein. Applications involving the apparatus and systems of various embodiments are broad and include a variety of electronic and computer systems. Some embodiments perform functions in two or more specific interconnected hardware modules or devices with associated control and data signals communicated between and through the modules, or as part of an ASIC. Thus, the exemplary system is applicable to software, firmware, and / or hardware implementations.

[0130] As used herein, the term "processing device" is intended to include any processor, such as one including a CPU (central processing unit) and / or other forms of processing circuitry. Additionally, the term "processing device" may refer to two or more individual processors. The term "memory" is intended to include memory associated with a processor or CPU, such as RAM (random access memory), ROM (read-only memory), fixed memory devices (e.g., hard drives), removable memory devices (e.g., diskettes), flash memory, etc. Additionally, the display device 912, input devices 914, cursor control devices 916, signal generating devices 920, etc., may be collectively referred to as an "input / output interface," which is intended to include one or more mechanisms for inputting data into the processing device 904 and one or more mechanisms for providing results related to the processing device. Input / output or I / O devices (including, but not limited to, a keyboard (e.g., alphanumeric input device 914), display device 912, etc.) can be coupled to the system directly (e.g., via bus 910) or via intervening input / output controllers (omitted for clarity).

[0131] In an integrated circuit implementation of one or more embodiments, multiple identical dies are typically fabricated in a repeated pattern on the surface of a semiconductor wafer. Each such die may include a device described herein and may include other structures and / or circuits. Individual dies are cut or diced from the wafer and then packaged as integrated circuits. Those skilled in the art know how to dices a wafer and package the dies to fabricate integrated circuits. Any of the example circuits or methods shown in the accompanying drawings, or portions thereof, may be part of an integrated circuit. Integrated circuits so fabricated are considered part of this invention.

[0132] According to various embodiments, the methods, functions, or logic described herein are implemented as one or more software programs running on a computer processor. Specialized hardware implementations, including but not limited to application specific integrated circuits, programmable logic arrays, and other hardware devices, can also be configured to perform the methods described herein. Furthermore, alternative software implementations, including but not limited to distributed processing or component / object distributed processing, parallel processing, or virtual machine processing, can also be configured to perform the methods, functions, or logic described herein.

[0133] Embodiments contemplate machine-readable or computer-readable media containing instructions 902, or receiving and executing instructions 902 from propagated signals such that devices connected to network environment 922 can send and receive audio, video, or data, and use instructions 902 to communicate over network 922. Instructions 902 are further transmitted and received over network 922 via network interface device 924. Machine-readable media also include data structures for storing data useful in providing functional relationships between the data and a machine or computer in exemplary embodiments of the systems and methods herein.

[0134] While machine-readable medium 902 is shown in the exemplary embodiment to be a single medium, the term “machine-readable medium” should be interpreted to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more sets of instructions. The term “machine-readable medium” is also interpreted to include any medium that can store, encode, or retain a set of instructions for execution by a machine and cause the machine to perform any one or more of the methodologies of the embodiments. The term “machine-readable medium” is therefore interpreted to include, but is not limited to, solid-state memory (e.g., solid-state drive (SSD), flash memory, etc.), read-only memory (ROM) or other non-volatile memory, random-access memory (RAM) or other rewritable (volatile) memory, magneto-optical or optical media such as disks or tapes, and / or digital file attachments to email or other self-contained information archives or sets of archives, and the like, are considered distribution media equivalent to tangible storage media. Thus, embodiments are contemplated to include any one or more of tangible machine-readable media or tangible distribution media, as enumerated herein, including art-recognized equivalents and successor media, on which software implementations herein are stored.

[0135] It should also be noted that software that implements the methods, functions, and / or logic herein is optionally stored on a tangible storage medium, e.g., magnetic media such as disks or tapes, magneto-optical or optical media such as disks, or solid-state media such as a memory vehicle or other package that stores one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories. Digital file attachments to email or other self-contained information archives or sets of archives are considered distribution media equivalent to tangible storage media. Accordingly, the disclosure is considered to include the tangible storage media or distribution media enumerated herein and other equivalent and successor media having stored thereon the software executed herein.

[0136] Although the specification describes components and functions performed in embodiments with reference to particular standards and protocols, the embodiments are not limited to such standards and protocols.

[0137] The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all elements and features of devices and systems that may utilize the structures described herein. Many other embodiments will become apparent to those skilled in the art upon reviewing the above description. Other embodiments may be utilized and derived therefrom, whereby structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. The drawings are also merely representational and not to scale. Certain proportions thereof have been exaggerated, while others have been reduced. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense.

[0138] Such embodiments are referred to herein individually and / or collectively by the term "embodiment" merely for convenience and without any intention to intentionally limit the scope of the present application to any one embodiment or inventive concept even if more than one is actually shown. Thus, while specific embodiments have been illustrated and described herein, it should be understood that any configuration calculated to achieve the same purpose may be substituted for the specific embodiment shown. The present disclosure is intended to cover any and all adaptations or variations of the various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those skilled in the art upon reviewing the above description.

[0139] In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate exemplary embodiment.

[0140] The Abstract is provided to comply with Title 37 Code of Federal Regulations Section 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing Detailed Description, various features may be grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as an indication of an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

[0141] While certain exemplary embodiments have been described, it will become apparent that various modifications and changes can be made to these embodiments without departing from the broader scope of the inventive subject matter described herein. Accordingly, the specification and drawings are to be regarded in an illustrative and not a restrictive sense. The accompanying drawings, which form a part hereof, show, by way of example, and not of limitation, specific embodiments in which the subject matter may be practiced. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to practice the teachings herein. Other embodiments may be utilized and derived therefrom, whereby structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. Accordingly, this detailed description is not to be construed in a limiting sense, and the scope of various embodiments is defined solely by the appended claims, along with the full range of equivalents to which such claims are entitled.

[0142] Given the teachings provided herein, one skilled in the art will be able to contemplate other implementations and applications of the techniques of the disclosed embodiments. Although exemplary embodiments are described herein with reference to the accompanying drawings, it should be understood that these embodiments are not limited to the disclosed embodiments, and that various other changes and modifications may be made to these embodiments by those skilled in the art without departing from the scope of the appended claims.

Claims

1. 1. An event-driven read management system with non-priority access arbitration for multiple channels, the system comprising: an arbitration tree circuit that determines which of the plurality of channels to grant access to a common signaling resource shared by the plurality of channels, the determination being based on a read access request provided by at least one of the plurality of channels, the arbitration tree circuit excluding multiple simultaneous read access requests from the determination, the read access requests being received by the arbitration tree circuit and stored in the arbitration tree circuit until access to the common signaling resource is granted by the arbitration tree circuit, and the arbitration tree circuit terminating a previous read transaction and initiating a subsequent read transaction in response to a single edge of a clock signal; a response circuit operatively coupled to the arbitration tree circuit, the state of the clock signal representing an acknowledge token, the acknowledge token being provided to the arbitration tree circuit, the arbitration tree circuit using the acknowledge token to grant access to the common signaling resource; an in-channel logic circuit operatively coupled to the arbitration tree circuit, the in-channel logic circuit generating the read access request and receiving the acknowledge token, the in-channel logic circuit terminating the previous read transaction and initiating the subsequent read transaction in response to receiving the acknowledge token; A system including an output periphery circuit, the output periphery circuit converting information received from the plurality of channels into an output format for the common signaling resource.

2. The system of claim 1 , wherein the common signaling resources include at least one of analog and digital signaling lines.

3. The system of claim 1 , wherein the read access request is generated in response to an event, the event including activation of at least one of the plurality of channels to generate transmissible data.

4. 2. The system of claim 1, wherein the read transaction includes multiple read phases, at least one of the multiple read phases resulting in the transmission of at least a portion of information from one of the multiple channels to the common signaling resource.

5. 2. The system of claim 1, wherein a duty cycle associated with the clock signal is selectable to define an acceptance time associated with the read access request and to ensure a settling time associated with the common signaling resource.

6. 2. The system of claim 1, wherein the determining further comprises determining which of the plurality of channels is granted access to the common signaling resource according to a plurality of read phases associated with the read transaction, independent of at least one of a read access request stored in the arbitration tree circuit, a received read access request, and a relative position of the plurality of channels with respect to the arbitration tree circuit.

7. 2. The system of claim 1, wherein a quantity of edges associated with the clock signal is equal to a quantity of read phases associated with the read transaction from one channel.

8. 2. The system of claim 1, wherein the arbitration tree circuitry operates asynchronously with the plurality of channels.

9. The system of claim 1 , wherein the arbitration tree circuitry operates synchronously with the output periphery circuitry.

10. 2. The system of claim 1, wherein the arbitration tree circuit operates synchronously with the in-channel logic circuit, the in-channel logic circuit operating asynchronously in generating the read access request, and the duration of the acknowledge token defines an acceptance window associated with the read access request for outputting data from at least one of the plurality of channels.

11. 2. The system of claim 1, wherein a duty cycle of the acknowledge token is selectable to provide data settling time after granting access to the common signaling resource.

12. 2. The system of claim 1, wherein the multiple channels contribute information to the common signaling resource, whereby transmission order associated with simultaneously requesting channels is independent of position associated with the simultaneously requesting channels within the arbitration tree circuitry.

13. 2. The system of claim 1, wherein the clock signal includes a first state and a second state, the first state being defined as active and including an acknowledge token that enables a new read access request to be accepted, and the second state disabling acceptance of the new read access request to avoid initiating data transmission with insufficient data settling time after being granted access to the common signaling resource in response to acceptance of the new read access request when the acknowledge token is routed to a new channel.

14. 2. The system of claim 1, wherein the read access requests processed by the arbitration tree circuitry include a logical OR of read access requests associated with at least one lower stage in the arbitration tree circuitry.

15. 2. The system of claim 1, wherein the read access requests processed by the arbitration tree circuitry include a logical OR of resulting signals from arbitration between read access requests.

16. 2. The system of claim 1, wherein the read access request processed by the arbitration tree circuit comprises a logical OR of a result signal from arbitration between the read access requests entering an arbitration cell and the clock signal including an acknowledge token at the arbitration cell.

17. 2. The system of claim 1, wherein the read access request processed by the arbitration tree circuit comprises a logical OR of a result signal from arbitration between a read access request entering an arbitration cell and the clock signal including an acknowledge token at the arbitration cell.

18. 1. A method for non-priority arbitration of multiple channels using an event-driven read management system, the method comprising: using an arbitration tree circuit to determine which of the plurality of channels to grant access to a common signaling resource shared by the plurality of channels, the determination being based on a read access request provided by at least one of the plurality of channels; The method comprises: using said arbitration tree circuit to exclude from said determination multiple simultaneous read access requests; The method comprises: receiving and storing said read access request in said arbitration tree circuit until access to said common signaling resource is granted by said arbitration tree circuit; The method comprises: using the arbitration tree circuit to terminate a previous read transaction and initiate a subsequent read transaction in response to a single edge of a clock signal; The method comprises: providing an acknowledge token to the arbitration tree circuit, the arbitration tree circuit using the acknowledge token to grant access to the common signaling resource, the state of the clock signal representing the acknowledge token; The method comprises: generating the read access request and receiving the acknowledge token using an in-channel logic circuit, the in-channel logic circuit operably coupled to the arbitration tree circuit; The method comprises: using the in-channel logic circuitry to terminate the previous read transaction and initiate the subsequent read transaction in response to receiving the acknowledge token; The method comprises: using output periphery circuitry to convert information received from the plurality of channels into an output format on the common signaling resource.

19. 1. A computer-readable medium containing instructions that, when executed by a processing device, perform operations, the operations including: using an arbitration tree circuit to determine which of a plurality of channels to grant access to a common signaling resource shared by said plurality of channels, said determination being based on a read access request provided by at least one of said plurality of channels; The operation is using said arbitration tree circuit to exclude from said determination multiple simultaneous read access requests; The operation is receiving and storing said read access request in said arbitration tree circuit until access to said common signaling resource is granted by said arbitration tree circuit; The operation is using the arbitration tree circuit to terminate a previous read transaction and initiate a subsequent read transaction in response to a single edge of a clock signal; The operation is providing an acknowledge token to the arbitration tree circuit, the arbitration tree circuit using the acknowledge token to grant access to the common signaling resource, the state of the clock signal representing the acknowledge token; The operation is generating the read access request and receiving the acknowledge token using an in-channel logic circuit, the in-channel logic circuit operably coupled to the arbitration tree circuit; The operation is using the in-channel logic circuitry to terminate the previous read transaction and initiate the subsequent read transaction in response to receiving the acknowledge token; The operation is A computer-readable medium comprising: converting, using output periphery circuitry, information received from the plurality of channels into an output format on the common signaling resource.

Images