( ESNUG 372 Item 5 ) -------------------------------------------- [05/31/01]
Subject: ( ESNUG 371 #17 ) Why Buy A 16550 UART When You Can Get It Free?
> 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: Rudolf Usselmann <rudi@asics.ws>
John,
Here is another work around:
Go to http://www.opencores.org and download a FREE 16550 compatible UART
(includes all source code).
- Rudolf Usselmann
---- ---- ---- ---- ---- ---- ----
From: Vladimir Sindalovsky <sindalovsky@agere.com>
John,
As for the bugs and fixes for DW_16550, John, you know that DesignWare HDL
is encrypted, and the only description I can try to fix is synthesized
netlist. That is why I relied 90% on Synopsys to fix the bugs I reported.
The only one I was able to fix myself was related to asynchronous ISA
interface. It was a commonplace error made in synchronizing ISA read and
write strobes. The signals were sampled once on the rising edge of internal
clock, and after that ANDed with the asynchronous strobe itself in order to
derive trailing edge of a strobe. Due to the asynchronous nature of the
strobes the resulting signal has a possible duration from 0 to one period
of internal clock. It was easy to additionally synchronize ISA signals in
DW_16550 wrapper, so now it is a two-stage shift register, and the trailing
edge pulse is always one period wide. However this imposes a limitation on
the minimum duration of the strobes as well as back-to-back timing, ISA bus
is slow enough in respect to the internal clock rate, so this cheesy fix
can be used.
The other bugs I found (which has been already fixed by Synopsys) are:
1. When different sources of the host interrupt are enabled, and multiple
events causing the interrupt occur, read of IIR (Interrupt
Identification) register causes not only the highest priority interrupt
to be cleared, but Transmitter Holding Register Empty (THRE) interrupt
source to be cleared too. When all other sources of interrupt are
cleared, THRE does not cause the interrupt, although this source is
enabled. IIR register reflects a No Pending Interrupt condition
under these circumstances. Line Status Register (LSR) still shows a
correct THRE status in bits 6 and 5.
2. This bug is a real deja vu because I helped to fix the exactly same bug
in the chip released several years ago. Bits 2, 3 and 4 in LSR are set
when a word at the top of RX FIFO has a break indication, framing error
or parity error correspondingly. Normally those bits are latched on the
read of the previous word from RX FIFO. However, if RX FIFO is empty
and the first character written into it has one of the mentioned errors,
it is immediately moved to the top of RX FIFO, and error bits has to be
latch on FIFO write rather than FIFO read. This bug exhibits itself under
described circumstances as an RX FIFO error bit (bit 7 in LSR) being set,
and neither one of bits 2, 3 or 4 ever set to a one.
The bugs, supposedly found by Ketchum, will be fixed in couple of weeks,
and the list of bugs was published by Synopsys in ESNUG last week.
- Vladimir Sindalovsky
Agere Systems
|
|
