VHDL Arbiter – part II

In the previous installment, we defined what a HW arbiter is. Let’s see a simple implementation of a VHDL arbiter.

The arbiter has three inputs and three outputs.

The logic is very simple. If the first master (master 0) asserts a request, it is awarded grant. Master 1 is given grant only if it requests the bus and master 0 doesn’t request the bus.



The logic for gnt selection is a priority encoder where only one gnt bit is asserted for any combination of req signals. Let’s see a Modelsim simulation of the thee-input arbiter.


Upon reset release, there are no outstanding requests so the arbiter also doesn’t assert any grant signals. Following the simulation, several masters ask permission from the arbiter (request asserted) and are given grant one clock later.

A general form of the code for this kind of arbiter is:


where the parameter ARBITER_W is the quantity of signals processed by the arbiter.

RTL – Fixed priority two port arbiter
RTL – Fixed priority three port arbiter
RTL – Four port VHDL arbiter with fixed priority

The RTL representations show the growing combinatorial complexity needed to take care of an increasing number of ports, and were generated with Quartus Prime 15.1. Note that some blocks (like the output FFs) are not single but stacked primitive instantiations.

As was described, if several masters request the bus, the master with the lowest number is given grant (recall that only one master shall receive grant at any given time). This arbiter has a fixed priority. Although it could be possible to use such an arbiter for certain applications, the most common type of arbiters don’t have fixed priority.

We will talk more about this in the next installment.


Proposed exercises

  1. As explained, this simple arbiter has a fixed priority. If several masters assert their request signals, the lowest numbered master is given grant. Design a fixed priority master where the highest numbered master has the highest priority.
  2. Many arbiters are requested to leave a ‘dead’ cycle to avoid collisions in the transition from one master to another. Modify the fixed priority arbiter, so there is one clock cycle where all the grant signals are de-asserted when switching between any two masters.
  3. In this arbiter, as long as a master requests a bus, the bus is granted to it. Add timeout logic. If one master asserts request for more than 10 clk periods, de-assert the grant signal to this master if other requests are outstanding.
  4. Some arbiters have a park feature. Park means that if there are no outstanding requests, the grant signal is given to the last master who received it. In another version, if no master asserts request, the gnt signal is assigned to a ‘default master’. Design code for each one of those two options.

Read the first part of this article

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s