01-31-2013 08:29 AM
I state that should not be a condition to function correctly.
But when the buffer fifo (for example in uart_rx6) reaches its maximum (pointer = '1111 'and buffer_full = '1'), if you add an input data without reading the data , pointer goes to '1100 'and buffer_full = '0' . If data continue to arrive I have a continuous sequence of pointer = '1101 ', '1110', '1111 ', '1100' and so on: pointer(3) and pointer(2) have fixed value but pointer(1) and pointer(0) have a rotate condition.
Is it this a desired condition?
02-05-2013 07:51 AM
Here are the descriptions taken from the ‘UART6_User_Guide_30Sept12.pdf‘ documentation relating to the ‘buffer_full’ status outputs…
buffer_full - Whilst it is possible to write one character into the FIFO every clock cycle the UART transmitter will always take many more clock cycles to serially transmit each character (e.g. 8,680 clock cycles at 115,200 baud using a 100MHz clock). It is therefore extremely easy to fill the FIFO with 16 bytes of data before the first character has been transmitted. It is vital that no attempt is made to write more data into the FIFO if the ‘buffer_full’ flag is active High (1). The most common technique employed in a application is to first test that ‘buffer_full’ is Low (0) before writing only one character to the transmitter FIFO. If the full flag is active then the application waits for it to return Low before writing just one more character and testing the ‘buffer_full’ flag again.
buffer_full - The receiver FIFO buffer can hold up to 16 characters. Obviously this means that up to 16 characters can be received from the serial input before the application needs to read any of them from the buffer. The ‘buffer_full’ flag will be driven active High (1) as soon as the 16th character is received since design start or the when the last read occurred. If this situation be allowed to develop in a application then it should be treated as a matter of some urgency to read at least one character from the buffer before a 17th character is received and results in a buffer overflow. Remember that it can appear to take a relatively long time (e.g. 8,680 clock cycles at 115,200 baud using a 100MHz clock) for the next character to be received so a rapid response to ‘buffer_full’ should avoid any loss of data. If however, the application is unable to determine the moment at which the ‘buffer_full’ flag was asserted then it will almost certainly need to assume that an overflow has occurred and take suitable recovery steps.
Like most things, the UART macros work correctly if used within their defined limits. Failing to recognise a full flag and taking suitable action it going to result in undesirable consequences regardless of how the macro itself behaves. It can be useful technique to adopt the ‘buffer_half_full’ status signal as a ‘full flag with a safety net’. In that way it can help you past an otherwise unexpected delay in servicing the UART macros (e.g. the servicing of an interrupt delaying the reading of a character from the ‘uart_rx’ buffer).
Remember also that these macros are highly optimised (only 5 Slices each) so you can always add further FIFO buffers in your own design to increase the overall capacity.