A. LeFevre, Howard

a VHDL 16550 UART core

Vivado 2016.4
FPGA: XCKU115

When trying to empty the RX Fifo, with CS and WR in single shot mode (only '1' for one clock cycle) and continiously reading the RX Fifo, the same read is outputted.

When doing a TX Fifo write followed by a RX Fifo read, the RX fifo counter is incremented. 

Example:

RX Fifo Read 20 times outputs last known TX Fifo (lets say 0x30) each read.

----------------------------

Tx Fifo Write 0x00
RX Fifo read, 0x30
TX Fifo Write 0x00
RX Fifo read, 0x31
...
...
...
Tx fifo write 0x00
Rx fifo read 0x00
..
..
Tx fifo write 0x01
Rx fifo read 0x01
Tx fifo write 0x02
Rx fifo read 0x02
..
..
Tx fifo write 0x20
Rx fifo read 0x20

--------------------------------

It seems that the TX and RX Fifo counters are correlated when they should be independent of each other. Is there something I am doing that is just incorrect or am I misnunderstanding something?

RX Fifo Counter

The bit for "Empty Transmitter Holding Register", is not set.
It is bit 6 of LSR.

So the Software does not see if the FIFO is full, if it is polling this bit. It keeps on writing into the FIFO after the 16 bytes are full and out comes garbage.

No "Emptx Transmit Holding" Bit is set

A bunch of source files are missing.

1. gh_edge_det.vhd
2. gh_register_ce.vhd
3. gh_DECODE_3to8.vhd
4. gh_jkff.vhd
5. gh_baud_rate_gen.vhd
6. gh_counter_down_ce_ld_tc.vhd
7. gh_edge_det_XCD.vhd

Missing Source Files

The VHDL 16550 UART generates an error using Xilinx iSim (I’m using 12.3 M.70d). Ther error is: 
ERROR: Value -2147483648 is out of valid range : 0 TO 8 

This is caused by line 29 of gh_uart_Rx_8bit.vhd, which reads: 
num_bits : in integer; 
I think that this should read 
num_bits : in integer:=8;

Xilinx iSim generates "out of valid range" error

Hi Howard,
 
I'm using your UART core with the associated gh library and I have some trouble. When the dividing register (DLM,DLL) is set to 1, to have the maximum baud rate, the UART simply don't work. After analyzing the design, I've located the problem in the gh_baud_rate_gen entity.
 
In this entity, when "rate" value is set to 1, the counter U3 is stopped and "count" output stay to value 1. Then the entity output "rCE" is fixed to '1'. Finally signal "BRC16x" in gh_uart_16550 entity is always '1'.
I've tried to use the "BR_CLK" input signal to directly drive the "rCE" output. But UART doesn't work. It works when using "not BR_CLK" but I can't explain why and it could be dangerous for synchronization.
 
Could you please explain me how the BRC16x is used in the UART entity. Do you have some idea to find out the problem or to solve it ?
 
info:
    gh_baud_rate_gen version 2.1
    gh_uart_16550 version 2.8
 
Thank you for your help.
 
Best regards,
 
Cyril BEGUET

UART and gh_baud_rate_gen

Problem:
Tx FIFO (U28) latch data two times on one ABP write cycle. Two wr pluses are generated on FIFO wr input. Edge detection (U3) in ABP wrapper detect two rising edge instead of one. There is a mistake in CS equation.

Solution:
in file gh_uart_16550_amba_apb_wrapper.vhd, line 171, change
CS <= '1' when ((PSEL = '1') and (PENABLE = '0')) else '0';
to
CS <= '1' when ((PSEL = '1') and (PENABLE = '1')) else '0';

CS in APB Wrapper

Bit 4 of the Line Status Register is meant to indicate whether a break state has occurred.  According to the datasheet for the PC16550D, this bit should be cleared when the LSR is read.  However, if the RBR register is read after reading the LSR register, and no additional data has yet come in, the Break Interrupt reappears.
This could be attributed to line 840 of gh_uart_16550.vhd which will set the "Break Interrupt" bit if RF_DO(10) is high.  Since this line never checks if the FIFO is empty (and, therefore, if the 11-bit word in the RX FIFO is valid), it will always keep iBreak_ITR at a logic one if the last byte in the FIFO is the break byte.  (Note the last byte in the FIFO never really "goes away" until another byte replaces it.)  When RBR is read, iBreak_ITR is pulled low briefly due to the RF_RD signal.  This allows component U32c to detect another rising edge and reassert the Break Interrupt bit.
It seems to me the code should not reassert the Break Interrupt bit if the break byte in question has already been read out.
I would recommend replacing line 840 with code similar to the following:
iBreak_ITR <= RF_DO(10) and (not RF_RD) and (not RF_EMPTY);

I'm open to other interpretations of the proper functionality, as I'm not fully confident in how I'm reading the PC16550D spec, but it seems like this is unexpected behavior.
Regards,
~Nathan Z.

Break state persists after condition cleared

Simulation of the UART shows that the transmit interrupt will be generated, as expected, even with a single byte transfer (the transmit FIFO becoming empty).

Transmit Interrupt doesn't fire during a Single Byte Send

When using the Receiver Line Status Interrupt (IER(2) = 1) I observe the following behaviour:

* A character with parity, framing or break error was received and the LS interrupt is set.
* When now the LSR is read, the LS interrupt is not cleared how it is described in the IIR.
* But when the top character from the Rx FIFO is read then the LS interrupt is cleared immediately.

What I expect is that the LS interrupt can be cleared by reading the LSR any time, independently of the top charater in the Rx FIFO.

Matthias Klemm

Clearing Receiver Line Status Interrupt

It is my understanding that an interrupt should be generated as soon as  the Transmitter Holding Register Empty Interrupt is enabled (bit 1 IER). My simulation shows this is not the case.
Linux driver (8250.c) flags this behaviour with UART_BUG_TXEN, so maybe this is not a bug and this behaviour is intended.

Enabling THRE Interrupt

FIFO resets work fine.  Examine signals TF_CLRS and RF_CLRS and how they work with U22 and U23.

Fifos' reset doesn't work

Timeout interrupts are now disabled with the receive interrupts enabled/disabled together.

Timeout interrupt

The comments about the clock configuration are correct.  The baud rate generator creates a clock enable which is used by the Transmitter and Receiver modules – they operate at the same rate as B_CLK.  

As long as the user wants to use the Baud rate generator to set the baud rate, there is no problem.  If some one wants to by-pass the Baud rate generator, it should be easy modify the source code.

Browse

a VHDL 16550 UART core