
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
John wrote regarding XAPP223: > > Occassionally, we are seeing a MISSED byte being sent from > a random serial device. > The XAPP223 UART has a flaw in the receive section that causes that problem- just re-clock the incoming data through a couple of registers, using the UART clock, before driving the UART data input. ( Internally to the macro, the UART input data is registered and used in more than one place without a synchronizer stage... ) Brian [EMAIL PROTECTED] (john orlando) wrote in message news:<[EMAIL PROTECTED]>... > Hello, > We have recently been using the free Xilinx UART macro with the > 16-byte FIFO (from app note XAPP223) in a design, instantiated in a > Virtex XC2V1000. We are using both the Rx and Tx macros (actually, 32 > of each for a total of 32 UARTs in the device). Our actual setup > looks like this: > > StrongArm SA-1100 <--> Virtex XC2V1000 <--> 32 serial devices > > where the UART FIFOs in the XC2V1000 are essentially memory-mapped > into the StrongArm's memory space to read and write to the serial > devices. > > Occassionally, we are seeing a MISSED byte being sent from a random > serial device. We have scoped the serial lines between the serial > devices and the XC2V1000 and know the serial data is showing up there. > We put a high-speed logic analyzer on the interface between the > SA-1100 and the XC2V1000, and know that the byte does not appear > there. > > After three weeks of investigating this issue, we are starting to > wonder if the lost byte may be due to the macro. Is there any > condition with the macro where performing a read from the UARTs Rx > FIFO to pull a byte out on the same clock edge where a stop-bit has > been received and recognized, and the received byte added to the Rx > FIFO, would cause the received byte to be lost? Specifically, it > seems as though we see N bytes in the UART's Rx FIFO to be read, we > perform N reads (actually, N+1 reads, because the N+1 read is what > indicates to us that DATA_PRESENT is not asserted, and that byte > should be thrown away...we do 16-bit reads: 8 bits data, and 8-bits of > status, with the DATA_PRESENT part of the status). We only see the > missing bytes when we eventually see DATA_PRESENT again, which > interrupts us (the interrupt is actually delayed 4-byte times in our > system), and we perform a read of the data in the Rx FIFO again. We > should be able to read 4 valid data bytes. However, the first byte we > read from the FIFO is actually the SECOND byte that should have been > in the FIFO, and the first byte is gone forever (the remaining third > and fourth byte are read just fine). > > Anyone out there ever seen this type of behavior with the macro > before? Our baud rates are running at 38.4 KBps, and our FPGA is > being clocked by the StrongArm at ~90 MHz, in case you're curious. > Any help would be appreciated....thanks in advance! > > Regards, > John O.
| <-- __Chronological__ --> | <-- __Thread__ --> |