Usenet.com

www.Usenet.com

Group Index

Comp Thread Archive from Usenet.com

<-- __Chronological__ --> <-- __Thread__ -->

Re: Xilinx UART Macro ERROR???



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__ -->


Usenet.com



Please check out one of the premium Usenet Newsgroup Service Providers below for access to Usenet.