UART 16550 core

Hallo, I'm not sure I found a bug but I used the core and I found a problem. I'm using 9600 baudrate with fifo trigger level set to 1 and no dma. Transmission goes perfectly but reception has the following strange behaviour: if I send to the UART the letter A, it receives another character (0). If, after letter A I send the letter B, it still receives 0. Only after 15 transmissions of characters, the UART actually receives letter A, and following another transmission of a character, it receives the letter B and so on. It seems that there is a delay of 15 characters that I can't remove. I've tried to reset the FIFO during initialization of the UART and tried to flush it but without any result. Can anyone help me?

Thank you Valentina

I've come across similar issues. I think it's to do with how the FIFO's are implemented in the design. It doesn't seem to port very well to FPGA architectures.

I have the exact same problem. Implemented on a Altera Cyclone II FPGA. I also have a problem with the transmit FIFO; It transmits each character it enter 14 times. Any ideas on how to get this code to port correctly?

Jason

Jason - I am using this core on an Altera Cyclone EP1C6Q240 and had the same problems, but making the modifications described by Oskar Lopez (search in forum) solved them. Change the receive FIFO for one from the GH_VHDL library (gh_fifo_async_usrf.vhd) and modify it as described. The only difference I found was where he describes adding the signal:

signal iRD : STD_LOGIC:='0';

I had a problem with compiling this with initialisation, so I have:

signal iRD : STD_LOGIC;

Which worked ok. Hope this helps.

Nigel

Thanks Nigel!
This fixed the recieve FIFO problem. However the transmit FIFO still has problems. I tried to use the library function gh_fifo_async_uswf.vhd with the same changes as the usrf version, and now the data loaded is transmitted (good), but 13x in a row starting with the last loaded value!

Jason

Sorry Jason - I forgot that I also had other problems using the core, with Tx, but these were due to interfacing issues with my processor bus and control lines (CS), and not particularly the core itself.

I'm using a Freescale Coldfire processor with 16 bit bus & found I needed an 8 bit latch on the RD port of the 16550 and also some other logic to control CS - to ensure that only a single CLK edge occurs while CS is valid - this is important otherwise you will get multiple writes. I'm using 4.096MHz for the bitrate clock which is derived from a 32.768MHz system clock (32.768/8) and 15.5MHz for CLK input to 16550, which is derived from the 60MHz processor clock (60MHz/4). When I first used the core & had problems (with Tx) I did some simulations and found that for some reason (as yet unexplained) the core did not work properly with a common bus going to both Tx & Rx ports - this is why I used an 8 bit latch on the Rx port which seems to work fine. It was only after I fixed the Tx problems that I realised the Rx also was not working properly - then I tried the fix described by Oscar Lopez & this sorted the Rx.

I will send you (off line) the 16550 part of my circuit which may help.

Hi Nigel,

I'm very interessed in the modification you've done on this circuit too. I'm not formed with verilog and I couldn't do the modifications as you describe.

I've got some problems too with this IP implemented on EP2C8 device. I just use this IP as RS232 protocol (use only Tx,Rx,CTS,RTS) First, I tried to communicate only with Tx/Rx and some bytes are lost during transmission. I think my problem comes from FIFO managing. I think the following post upped on the reported bugs by el_tacano76@h... on 21-Dec-2005 is the problem.

This is because the fifo latches in the data the clock cycle after the write enable. If your write data remains valid for one more clock cycle then there is no problem, if the write data changes after the write enable (As in my case) you will get garbage written to the transmit fifo. As chenxj suggested changing the tf_push to combinational so it is valid one clock cycle earlier will fix the problem.

The autor of the IP say also in the description of the uart_regs.v that there is a known problem and that it could be fixed with inserting a wait state on all wishbone transfer... I'm trying to do this but without success for the moment.

Have you got an idea ? Thanks.

Solutions for Valentina's problem?