You are here: HomeTutorialsTutorial 1 - A Serial Communication FPGA Debug ModuleTutorial 1: Part 3 - The Unified Control and Status Register

Tutorial 1: Part 3 - The Unified Control and Status Register

1.3.1 Introduction


The aim of this part of tutorial series 1 is to architect and implement the control and status registers. If all goes well we should be able to connect their outputs to the inputs of the, yet to be developed, protocol wrapper TX core. Then we should be able to test the setup in real hardware, similar to the loop back test performed in part 1 of the tutorial.

Therefore the aim of part 3 is to implement two registers, the write only control register and read only status register. Also, the protocol wrapper TX core should be implemented. Next the ensemble, including the protocol wrapper RX core and the UART core, should be tested on the DE0 Nano Development and Education Kit. 

1.3.2 The Control Register and the Status Register

The inter-connection between the control and status registers and the protocol wrapper can be seen, in Figure 1.3.1, below. It can be seen that the control register has no connections to the protocol wrapper TX module, as it should consist of a series of write only registers. When the control register receives data it stores the data in a register corresponding to the input register number, reg num.

This occurs  when the write reg enable, write reg en, flag is asserted. If the register does not exist, in a known register range,  an unknown register error, UNKNOWN_CONTROL_REG_ERROR, is flagged and the error register is notified. The error register transmits this notification on to the PC user. For now we will ignore the protocol requirements, listed in Table 1 (part 1), that we should acknowledge control register messages. The overall concept and protocol is about to change anyway, as you see in the section below.


Figure 1.3.1 The control and status registers.

The status register is slightly more complicated, as it has to interact with both of the protocol wrapper RX and TX modules. The status register receives data in the same way as the control register, except that its  read register enable, read_reg_en,  flag is asserted,  rather than the control register's write enable flag. When this read flag is asserted an algorithmic state machine kicks in. The ASM is used to sequence transmission between the core and the protocol wrapper TX module. When the status register is ready to transmit data, it requests a transmission slot from the protocol wrapper TX module. When this request is acknowledged, by the protocol wrapper TX core, transmission can begin. A state machine that could be used to sequence the status register's transmission sequence can be seen in Figure 1.3.2


Figure 1.3.2 The status register's Finite State Machine (FSM). When the read enable flag is asserted, a 32-bit data word is transmitted, if the register to read from is valid. If it is not valid an error is flagged.

An architectural diagram showing both cores, side by side, can be seen, in Figure 1.3.3,  below. To test the cores, only a single register is implemented in each of the control and status register modules. Also, the output of the control register is redirected to the input to the status register. This allows us to write to a control register and verify its value by reading from the corresponding status register. Note that for the case of the control register the four bytes of incoming data are converted into a 32-bit data word. Conversely, the data in the individual 32-bit  status registers are stored data in 4 bytes to ease transmission.


Figure 1.3.3. Architectural diagram of the control and status registers.

Before we begin coding this module it is interesting to reconsider the read only status register and the write only control register. What would happen if we combined these two registers into a single read-write register? We could implement such functionality as a read write register core, that would consist of a number of these combined registers. Also, we could ease the design of the core by transferring the error detection logic to the error register. As can be seen, in Figure 1.3.4, we have just made our design simpler, but more effective.

1.3.3 The Unified Control and Status Register Core

The unified control and status register core consists of the set of individual control registers and the individual status registers, combined into a set of read-write registers. When register reads occur, an ASM is responsible for coordinating reading from the addressed register. It sends a transmit request, TX Req, notice to the protocol wrapper TX module and awaits a response. Then, after a transmit acknowledgement, TX Ack,  is received the data read is passed, a byte at a time, to the  protocol wrapper TX module for transmission, but only when the transmitter busy flag, TX_BUSY, is deasserted.


Figure 1.3.4.  The unified control and status register architecture. In this schema the control and status registers, described previously, have been combined into a set of individual read-write registers. Errors handling is now decoupled from the register and are now handled directly by the error register. The error register issues an undefined register message when a register number is undefined, REG_NUMBER_UNDEFINED_ERROR.

When a write register message is received, the register number is decoded by an address decoder. The decoded register enable signal, corresponding to the register number of the write message, is asserted. Although data is written into the register a byte at a time, it appears as a continuous 32-bit word at its control output. When 4 bytes of data have been received, by each individual register, the corresponding control enable flag is asserted.

To provide write only control registers and read only status registers, with user attached logic, the schema shown in Figure 1.3.5 can be used. In both cases user status registers have been incorporated into the design, by allowing external status inputs. Thus, a user register can be read as a status register, when reading a read-write register.


Figure 1.3.5: A modification to the unified register turns it into a control write register and status read register. In the first variant, above, the user has to manually loop back the control data output to the external status input. By doing this the user can read the status of a control register. If the loop back is not applied the status register can be linked to the user's logic.

The second method is slightly more complicated and involves multiplexing, within the register,  between the  control register status and an external status signal. When the register type select , reg type,  is asserted low the source of the status register is the control register. When it is asserted high the source of the status register is a user defined register. For the purpose of this tutorial the first method will be employed.

The unified control and status register consists of an Algorithmic State Machine (ASM), that contains control and decision logic. It is used to sequence the transmission of the register number, as well as the status register's four bytes. When a read register enable, read_reg_en, command is received the state machine transitions out of the IDLE state. In the next state, the one it transitions to, it sends a transmission request message to the protocol wrapper tx module and awaits an acknowledgement. The acknowledgment is received when the TX acknowledge signal, TX_ack, is asserted.

When the UART TX core is not busy the state machine sets the source of the transmission data to the register number, of the register currently being read.  It then transmits this number. Next, the source of the transmission data is set to the status register. Again the state machine waits until the end of transmission of the last byte sent, by monitoring the TX busy flag. Then, the state machine goes through a transmission sequence of sending the four bytes of the status register, a byte at a time. The first few states of the state machine that achieves this task is shown,  in Figure 1.3.6, below.


Figure 1.3.6: The state machine of the unified control and status register. The first few states before the iterative byte transmission can be seen.

The implementation and simulation results are presented next.

1.3.4 The Unified Control and Status Register Core Implementation

This section provides the implementation details and the simulation results of the unified control and status register, seen in Figures 1.3.7 and 1.3.8. The ctrlType contains the control output and enable signals. The module has been implemented with internal loop back, which will be changed to use the external loop-back, method 1, in the next revision of the entity. To simulate the entity the unified control and status register has been connected directly to the UART's transmission module. This is because the protocol wrapper TX is yet to be developed. 


In this testbench the following sequences of messages have been sent:

  1. Write 0xEFBEADDE to control register 6 - Message 1 : 0x01 0x06 0xEFBEADDE
  2. Read status register 6 - Message 2 : 0x03 0x06
  3. Write the user defined message containing 8 bytes - Message 3 : 0x05 0x08 0xFFFEFDFCFBFAF9F8
The result of simulating the unified control and status register can be seen in Figure 1.3.8. The simulation has been performed when the control output from register 6 has been loop backed into the status register 6 input. The results are as expected. It shows that the value 0xEFBEADDE has been written to the control register 6 and the same value has been read from it, through the corresponding status register.


Figure 1.3.8 : The testbench signals of the unified control and status register. The outputs of the control register have been looped back into the status register.

1.3.5 Aftermath 

So what has been achieved so far? Well according to the overview diagram, in Figure 1.3.9, we have few modules left to program. However, in order to thoroughly test the work carried out up to this point what we really need to do is to write the application software. This will not only allow us to inject messages into the DE0 Nano development board,  in real-time, it will also allow us to start integrating the communications cores into practical applications. Previously, it was decided that the software could either be written in C++ using QT, or in Java using the Swing framework.

We will make a start with Java using the NetBeans development platform. This will be the main focus of the next part in the series. It will allow us to set up a permanent hardware/software test environment, before we move on to tidying-up the existing code and implementing the remaining modules. The statistics engine has yet to be implemented too.


Figure 1.3.9 : The DE0 Nano Serial Communication Protocol Architecture Overview.


 1. Circuit Design with VHDL, Volnei A Pedroni, MIT Press, Aug 2004.

Go to comments start