Browse Prior Art Database

Central Arbiter Optimized for Performance and Timing

IP.com Disclosure Number: IPCOM000116788D
Original Publication Date: 1995-Nov-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 92K

Publishing Venue

IBM

Related People

Barrett, WM: AUTHOR

Abstract

A specialized central arbiter is disclosed for a multiple-master digital bus. This bus incorporates multiple priority level requests and requires guaranteed fairness in a master's access to the bus. The key novelty of this central arbiter is that it is optimized for timing (i.e., minimizing the clock cycle time).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Central Arbiter Optimized for Performance and Timing

      A specialized central arbiter is disclosed for a
multiple-master digital bus.  This bus incorporates multiple priority
level requests and requires guaranteed fairness in a master's access
to the bus.  The key novelty of this central arbiter is that it is
optimized for timing (i.e., minimizing the clock cycle time).

      A Central Processing Unit's (CPUs) system bus is in need of a
centralized arbiter to grant usage of this bus to the multiple
devices that can become the "master" of the bus.  Each potential
master sends a "Request" to the arbiter, with each request having a
specific priority level.  This arbiter must guarantee equal access
between requests of the same priority level; plus, there must be some
"fairness" built-in to ensure that the higher priority levels cannot
lockout the lower priority levels.

      The timing constraints of this arbitration mechanism require
that a Grant must be able to be activated one bus clock cycle after a
Request is activated.  In other words, the logic and signal delay
from the Request output of a Master to the Grant output of the
Arbiter must be less than or equal to one bus clock cycle.  System
requirements also state that the soonest back-to-back Grants may be
given out is every other cycle.  Fig. 1 shows conceptually the amount
of logic (i.e., the decisions to take place) within the arbiter,
which need to execute in less that one clock cycle.

      In some integrated circuit technologies and with certain clock
cycle time goals, the above timing path could be very difficult to
achieve.

      In coming up with an optimal implementation that incorporated
all of the required functions any yet met the timing requirements,
the following two ideas played a key role:
  1.  At times when the system bus is not being used very much and
       there is only one Request active at a given time, all of the
       sophisticated processing of the Requests (to see which one
should
       be granted) isn't necess...