International Business Machines Corporation

Harrison M McCreary

Jeffrey A Stuecheli

Benjiman L Goodman

Daniel C Howe

William John Starke

Eric Eugene Retter

Stephen J Powell

Charles Francis Marino

Steven Leonard Roberts

Mark L Rudquist

A method for processing a token at a local device in a distributed arbitration system includes: receiving a first signal from first device indicating a request for access to a shared resource; receiving an indicator from a processing component of the local device indicating whether the processing component requires access to the shared resource; receiving a second signal from the local device, where a component of second signal indicates whether the local device has greater priority than another device in the set of one or more devices to access the shared resource; receiving a token from the chain network, the token granting a device access to the shared resource; determining a disposition of the token using the first signal and the second signal; disposing the token to allocate the shared resource to a device in response to the determined disposition; and updating the second signal in response to the determining.

Data token management in distributed arbitration systems

Managing starvation in a distributed arbitration scheme including sending, by a starved local arbiter, a starvation message toward a head arbiter, wherein the starvation message comprises an identifier of the starved local arbiter and a request for resources to transfer data to a destination, wherein the requested resources comprise a destination token and a bus slot; receiving, by a neighboring local arbiter, the starvation message, wherein the neighboring local arbiter is between the starved local arbiter and the head arbiter; if the neighboring local arbiter currently has the resources requested in the starvation message: marking, by the neighboring local arbiter, the requested resources with the identifier of the starved local arbiter.

Managing starvation in a distributed arbitration scheme

A unified request queue includes multiple entries for servicing multiple types of requests. Each of the entries of the unified request queue is generally allocable to requests of any of the multiple request types. A number of entries in the unified request queue is reserved for a first request type among the multiple types of requests. The number of entries reserved for the first request type is dynamically varied based on a number of requests of the first request type rejected by the unified request queue due to allocation of entries in the unified request queue to other requests.

Dynamic reservations in a unified request queue

A bypass mechanism allows a memory controller to transmit requested data to an interconnect before the data's error code has been decoded, e.g., a cyclical redundancy check (CRC). The tag, tag CRC, data, and data CRC are pipelined from DRAM in four frames, each having multiple clock cycles. The tag includes a bypass bit indicating whether data transmission to the interconnect should begin before CRC decoding. After receiving the tag CRC, the controller decodes it and reserves a request machine which sends a transmit request signal to inform the interconnect that data is available. Once the transmit request is granted by the interconnect, the controller can immediately start sending the data, before decoding the data CRC. So long as no error is found, the controller completes transmission of the data to the interconnect, including providing an indication that the data as transmitted is error-free.

Growing community of inventors

Austin, TX, United States of America

Harrison M McCreary