( ESNUG 371 Item 17 ) ------------------------------------------- [05/23/01]
Subject: ( ESNUG 370 #5 ) Seven Workarounds On Nine DW_16550 UART Bugs
> Recently I encountered the Ketchum tool you mentioned in your SNUG'01
> Trip Report. We were using DW_16550 UART in our design, and during usual
> simulation process, I uncovered few functional bugs. We were close to
> the tape out, so the situation was very tense, but, luckily, Synopsys's
> designers came up with a quick fix. It would be better not to have bugs
> in Synopsys DW IP at all, but "nobody's perfect".
>
> - Vladimir Sindalovsky
> Agere Systems
From: [A Synopsys DesignWare CAE Manager]
Hi, John,
If you are using the DW_16550, please read the details below, and upgrade
to the new release as soon as it's available. The target date for the
release is June 15, 2001. DesignWare customers will be able to download
this via: www.synopsys.com/designware/dwest. The "What's New" link will
indicate the release contains fixes for the DW_16550 part.
The only bug that we do NOT plan to fix in the next release is the last one,
"Under certain conditions, the DW_16550 asserts the txrdy_n and rxrdy_n
signals one clock cycle late [STAR 121181]."
1.) The DW_16550 loses Line Status Error Conditions when the Line Status
Register is read on the same clock cycle that data is being pushed
into the receive FIFO [STAR 121180]
If the following conditions are all true:
- DW_16550 in Synchronous Mode (sync_mode parameter = 1)
- FIFOs are enabled
- Receiver FIFO is empty
- Line Status Register is read on the same clock cycle that a
character is pushed into the Receiver FIFO
OR, if all of the following are true:
- DW_16550 in Asynchronous Mode (sync_mode parameter = 0)
- FIFOs are enabled
- Receiver FIFO is empty
- Line Status Register is read one clock cycle after a character is
pushed into the Receiver FIFO
This problem will occur:
In FIFO mode, the DW_16550 should push the Parity Errors, Framing
Errors and Break Interrupts, into the Receiver FIFO so that they appear
at the same time as the character that they are associated with. In
the conditions described above, the DW_16550 will lose the error flags
and they will not appear when the corresponding character is at the top
of the Receiver FIFO. The interrupts associated with these error
conditions will also not be raised. This problem will not occur if the
Line Status Register is always read in response to an interrupt or
activation of the txrdy_n or rxrdy_n signals. This problem may occur
if the CPU polls the DW_16550 instead of using interrupts.
Workaround:
Use interrupts or the txrdy_n and rxrdy_n signals to control reads and
writes to the DW_16550. Do not use the DW_16550 in polling mode.
2.) The DW_16550 doesn't assert the txrdy_n signal correctly in DMA Mode 0
[STAR 121177]
If the following conditions are all true:
- FIFOs are enabled
- DMA Mode 0 enabled
This problem will occur:
If FIFOs are enabled and DMA Mode 0 is selected (FIFO Control Register
Bit 3 = 0), the txrdy_n signal should go inactive as soon as a
character is written to the transmit FIFO. In the DW_16550 the txrdy_n
signal doesn't go inactive until several characters have been received.
Workaround:
None.
3.) The DW_16550 does not hold the Modem Status Bits and Serial Data Out at
logical '1' when in Loopback Mode [STAR 121161]
If the following condition is true:
- DW_16550 used in Loopback Mode
These problems will occur:
1. When it's in loopback mode the DW_16550 should hold the Modem
Status Bits (out1_n, out2_n, dtr_n, rts_n) at static '1', instead
it continues to assert the normal values.
2. When it's in loopback mode the DW_16550 should hold the Serial
Data Output (sout) signal at static '1', instead it continues to
assert the normal values.
Workaround:
None.
4.) The DW_16550 does not reset the FIFOs if they are disabled and
re-enabled during operation [STAR 121171]
If the following conditions are all true:
- The transmit or receive FIFO contains data
- FIFOs are disabled using FIFO Control Register bit 0
- FIFOs are re-enabled without clearing them using FIFO Control
Register bits 1&2
This problem may occur:
When you disable the FIFOs using FIFO Control Register bit 0, the FIFOs
are supposed to be reset automatically. The DW_16550 does not reset
the FIFOs. So, when you re-enable the FIFOs (using the same Control
Register bit 0), they will still contain the old data.
Workaround:
If you disable the FIFOs, then re-enable them, use bits 1 and 2 of the
FIFO Control Register to reset the Transmit and Receive FIFOs.
5.) When data is read from the DW_16550 very late, the DW_16550 status
flags may be incorrect [STAR 121173]
If the following condition is true:
- The CPU reads the RBR on the last possible clock cycle
These problems will occur:
In correct operation, once the DW_16550 has signaled that a character
has been received, the CPU has until the next character has been
received to read the data and clear the RBR. In FIFO mode, once the
FIFO is full, the CPU has until the next character has been received
to read one character from the receive FIFO. If the CPU fails to read
the data in time, an Overrun Error condition results.
There is a bug in the DW_16550 that causes the component to incorrectly
flag an Overrun Error if the CPU reads data and clears the RBR on the
last clock cycle before the overrun error would have occurred. Under
these conditions the DW_16550 incorrectly flags an overrun error, when
there is none. Specifically:
1. If new data is being pushed into the RBR on the same clock cycle
that the CPU is reading that data, the Data Ready (DR) bit of the
Line Status Register will not go active, even though new data is
there. This also affects the main Data Available Interrupt.
2. If new data is being pushed into the RBR on the same clock cycle
that the CPU is reading that data, the DW_16550 incorrectly
asserts an Overrun Error condition, even though none occurred.
Workaround:
There is no workaround for this problem. A system that is slow enough
in responding to Receiver Line Status Interrupts to see this problem
is probably also suffering from numerous legitimate overrun errors and
needs to have its response time improved.
6.) rxrdy_n continues to signal character timeouts, even when the receive
FIFO is empty [STAR 121173]
If the following conditions are all true:
- FIFO mode enabled
- DMA Mode 1 enabled
- You are using rxrdy_n to control when you read the receiver FIFO
This problem may occur:
When FIFOs are enabled and you are using DMA Mode 1, the DW_16550
should assert the rxrdy_n signal when the receiver FIFO level matches
the programmed threshold. In addition, the DW_16550 should assert
rxrdy_n when no data is read or written to the Receiver FIFO for a
period of four character times AND there is at least one character in
the receive FIFO. In this second case, the DW_16550 incorrectly
asserts rxrdy_n even when there is NO data in the receive FIFO.
The DW_16550 asserts the rxrdy_n signal on character timeout to trigger
the CPU or DMA controller to flush any data remaining in the receive
FIFO once no more characters are being received on the serial input.
If the rxrdy_n signal of the DW_16550 is used in this way, and the CPU
or DMA controller reads the receivreceive FIFO when the rxrdy_n signal goes
active on character timeout without checking the Line Status Register,
the data read will not be a valid character.
Workaround:
1. If DMA Mode 0 is used, the rxrdy_n behavior is correct.
2. When the rxrdy_n signal is active, read the Line Status
Register to determine if a valid character is available
in the receive FIFO.
3. Use the Received Data Available interrupt instead of the
rxrdy_n signal to control reading the Receiver Buffer Register.
7.) A write to the transmit FIFO followed immediately by a write to
configuration register fails [STAR 121178]
If the following conditions are all true:
- DW_16550 in Synchronous Mode (sync_mode parameter = 1)
- FIFOs are enabled
- Back-to-back write to the Transmitter FIFO followed by a write
to any of the configuration registers
This problem will occur:
If a character is written to the transmit FIFO, and on the next clock
cycle data is written to any of the DW_16550 configuration registers,
the data intended for the configuration register will be written to
the Transmitter FIFO instead.
Workaround:
This is not a normal mode of operation. It would be very unusual to
write a character to be transmitted and then, on the next clock cycle
before the character has been sent, to change the configuration of the
DW_16550. To workaround this problem, allow at least one clock cycle
between writing a character to the Transmit Holding Register and
writing data to a configuration register.
8.) If a write to the Transmit Holding Register is followed immediately
by a read of the Line Status Register, the DW_16550 will generate
incorrect status [STAR 121179]
If the following conditions are all true:
- A character is written to the Transmit Holding Register and, on
the very next clock cycle, the Line Status Register is read
- The system is using the Transmitter Empty status bit of the Line
Status Register
This problem will occur:
As soon as a character is written to the Transmit Holding Register, the
DW_16550 should set the Transmitter Empty status bit of the Line Status
Register false. If a read of the Line Status Register occurs on the
clock cycle following a write to the Transmit Holding Register, the
Transmitter Empty status bit will incorrectly indicate that the
transmitter is completely empty.
Workaround:
If you use the Transmitter Empty status bit, work around this problem
by always allowing at least one clock cycle between a write to the
Transmit Holding Register and a read of the Line Status Register.
9.) Under certain conditions, the DW_16550 asserts the txrdy_n and rxrdy_n
signals one clock cycle late [STAR 121181]
NOTE: This STAR will NOT be fixed in the upcoming release targeted for
6/15/01.
If the following conditions are all true:
- DW_16550 in Synchronous Mode (sync_mode parameter = 1)
- FIFOs are enabled
- DMA Mode 1
- txrdy_n signal is checked on the same clock cycle as a write to the
Transmitter FIFO or rxrdy_n signal is checked on the same clock
cycle as a read from the Receiver FIFO
OR, if all of the following are true:
- DW_16550 in Asynchronous Mode (sync_mode parameter = 0)
- FIFOs are enabled
- DMA Mode 1
- txrdy_n signal is checked on the first cycle after a write to the
Transmitter FIFO or rxrdy_n signal is checked on the first cycle
after a read from the Receiver FIFO
This problem will occur:
If back to back writes to the Transmitter FIFO are being gated by the
txrdy_n signal, the txrdy_n signal will become inactive one clock
cycle after the Transmitter FIFO is full, potentially causing a FIFO
overflow. If back to back reads of the Receiver FIFO are being gated
by the rxrdy_n signal, the rxrdy_n signal will become inactive one
clock cycle after the FIFO is empty, potentially causing a FIFO
underrun.
Workaround:
If the txrdy_n or rxrdy_n signals are to be used to gate a series of
writes to the Transmitter FIFO or reads from the Receiver FIFO, do not
do back-to-back reads or writes. Allow at least 1 clock cycle between
reads to the Transmitter FIFO or reads from the Receiver FIFO.
John, I hope this helps your readers. In the DesignWare Group we like to
keep our customers informed of bugs and their workarounds as soon as we
find them. Our customers like this type of pro-active support. :)
- [A Synopsys DesignWare CAE Manager]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
