You are here: HomeTutorialsTutorial 1 - A Serial Communication FPGA Debug ModuleTutorial 1: Part 6 - A Transmission Arbitration Module

Tutorial 1: Part 6 - A Transmission Arbitration Module

0000630To alleviate the poverty of flexibility in our existing design, described in previous parts of the tutorial, a revision to the design has had to be considered. This has resulted in the development of a transmission arbitration module. Thus, the overall objectives of part six, of tutorial series 1, is to firstly design and implement a round-robin transmission slot arbitration module that can be used in conjunction with the UART module developed previously. Then, secondly, a real-world example should be demonstrated on the DE0-Nano Development Kit platform.

 The purpose of the module is to provide FPGA designs with the functionality to arbitrate between multiple internal functions that attempt to transmit messages independently, using the UART. That is, entities that attempt to transmit messages to a host PC without firstly receiving a request for data message from the host.

In this module all functions have an equal chance of transmitting and can do so by assert their Request To Send flag, as can be seen, in Figure 1, below. A typical environment where this arbitration module could be used is in a FPGA design with say, for example, error and status registers that are required to periodically send updates of their status to a host PC. This action should be performed independently and without the host firstly sending messages to the FPGA enquiring about the health of the system.


Figure 1: Transmission Arbitration Timeline: In this example three transmission slots are available for 3 transmission functions. Each function firstly issues a request to send, RTS, command and expect a request to send acknowledge, RTSA, in return. If the function owns the current transmission slot and a RTSA has been receive it can begin transmitting, otherwise it must wait for its time slot to become available.

The second objective of the tutorial is to demonstrate how the operation of the newly developed arbitration module can be verified, quickly and efficiently, using SystemC. The third and final objective is to present a working example of the transmission arbitration module implemented on the DE0-Nano Development kit (review link), connected to a LINUX box and utilising FTDI's ftd2xx library in a multi-threaded GUI environment.


The serial debug protocol iteratively developed in Tutorial parts 1 - 5 has been useful in sending a set register or get register message from a host and receiving a response from the embedded logic within a FPGA. All in all the protocol has worked rather well. However, as mentioned previously, the poverty of flexibility in the protocol becomes evident when an attempt is made to use it in an environment that requires autonomous and concurrent operations to transmit messages, sometimes simultaneously.

This has required us to rethink and revise, yet again, how a general purpose protocol could be used effectively. This is because our previous protocol has been designed specifically as a send-receive protocol, which does not lend itself well to autonomous transmissions. A better approach could be to design the protocol using some kind of round-robin, time-slot technique that allows embedded functions to send messages to a master device unaided.


Figure 2: The Transmission Arbitration Core allows transmission between multiple functions and the UART core unaided.

However, the discussion on any changes made to the existing protocol is left, probably, to the next article in this series. In this article, we focus only on the round robin, time-slot technique and introduce the use of a transmission arbitration module. This module will become our TX Arbitration module and its relationship to the UART developed previously can be seen, in Figure 2, above.

To summarise, this article presents a discussion on an implementation of a transmission arbitration model, which uses the notation of time slots. The article also describes how the model is verified using SystemC and how it can be implemented in the real-world using the DE0-Nano.

Design Concept and Implementation

The conceptual design of the TX Arbitration module, the block diagram of which can be seen, in Figure 3, below, is the topic of discussion of this section. The TX arbitration unit consists of three major components, a transmission slot register, a finite state machine, which is used to control the transmission slot register, and a fault detection register.


Figure 3: The TX Arbitration Module is primarily driven by a finite state machine, which controls a transmission slot register. A fault detection register along with some glue logic completes the setup.

The module also incorporates glue logic to ensure that only a single Request To Send signal can be asserted at any one time. The glue logic is also used to ensure that only one transmission Send Complete flag, corresponding to the active transmission slot, can be asserted at a time. A description of the three major components, mentioned above, is provided below.

The Transmission Slot Register

The transmission slot register, item (2) in Figure 3 above, could be considered to be a modified rotation register, in which only one bit position can have a logic value of one at any given time. All the other bit positions should have a logic value of zero. If the modified rotation register has the bit one assigned to its LSB position on power-up then on each assertion of its enable signal the bit is shifted one bit position to the left.

The bit position, which is occupied by the logic value one, corresponds to the transmission slot that is currently active or has transmission rights. For example, if bit position 5 has a logic value of one, then only transmission slot 6 should be active and have the right to transmit. If each operation that wishes to transmit a message, through the UART, is associated with a transmission slot, then, as can be seen in Figure 3, only one operation can transmit data at any one time.

The other functions must wait for their transmission slot to become available. On each successive update of the transmission slot register the logic value 1, which effectively denotes the active transmission slot, is shifted one bit position leftwards. It is this process that rotates the transmission rights between slots.

If the operation associated with a particular transmission slot has data to transmit the arbitration model's state machine is paused, in the transmission state, TX, while transmission occurs. Otherwise, the state machine is advanced, effectively offering transmission rights to the next slot. These events are repeated until the logic value '1' is in the most significant bit position, corresponding to the highest slot number, where it is rotated back to the least significant bit position or lowest slot number in the next arbitration round.


Figure 4: The Transmission Slot register could be considered to be a rotation register that is only allowed to rotate one bit position at a time.

As mentioned previously, the transmission slot register is controlled by a Finite State Machine (FSM), which determines when the cyclic activity of each transmission slot occurs. A description of the FSM is the subject of the next section.

The Finite State Machine