Zilog Z16C30 - Manual (Page 196)

B-2
Z16C30 USC ®
U SER ' S M ANUAL
UM97USC0100
Z ILOG
General Questions and Answers (Continued)
Q: New and old samples of the USC act differently when
programmed to interrupt or DMA request when 1 byte
is in the Rx FIFO when used a 16-bit bus. Why?
A: On a 16-bit bus, USCs with data codes of 9136 and
older will interrupt and DMA request when two bytes
are available in the Rx FIFO even when programmed
to request on one byte. This allows the fill level to be
programmed to any level and DMA transfers would be
well behaved. USCs with data codes 9137 and newer
will interrupt and DMA request when one byte is in the
Rx FIFO if so programmed. Therefore, when using
DMA on a 16-bit bus, the Rx DMA request level should
be programmed to request when a minimum of 2 bytes
are available. Otherwise, the DMA will try to transfer a
word when only a byte is valid and cause invalid
characters to be placed in memory.
Q: When reading the Test Mode Data Register (TMDR)
the access time is three times normal. How does this
affect the AC timings?
A: Reading the TMDR (this applies to this register only),
the Data Valid Delay is stretched. This impacts the
following specifications:
#1 Bus Cycle Time
#9 /DS Fall to Data Valid Delay
#33 /RD Fall to Data Valid Delay
#79 /RDY Fall to Data Valid Delay
Q: How are the current state of the /CTS and /DCD pins
monitored using the latch/unlatched command/status
bits?
A: When the Latched/Unlatched status bit in the MISR is
zero, reading the MISR reports the current unlatched
state of the pins. When the Latch/Unlatched bit is set,
the current state of the pin can be found by writing a
one to the latch to clear it and then re-reading the
MISR.
Q: Does the USC family have on-chip protocol process-
ing similar to some other data communications chips?
A: No, Zilog data communication products do not have
on-chip protocol processing. This has not been built
into our chips since it greatly increases die size and,
consequently, cost. Also, many customers report that
they are not able to use the “auto” modes of protocol
processing chips because of their strict limitations on
how they respond...you must make your application
work the way the chip does or you can’t use the chip.
The versatility of the USC family offers a cost effective
solution to adapting chips to meet many application
needs. Next generation products may include inte-
grated CPUs to provide on-chip protocol processing
to meet application needs where appropriate.
Q: What Application Notes are available?
A: The following Application Notes are available. The
devices each App Note applies to is shown in brack-
ets. Design a Serial Board to Handle Multiple Protocols
[USC ] Using the USC with MIL-STD 1553B [USC,
IUSC] Data Communications with the Time Slot As-
signer [IUSC] Using the Zilog Datacom Family with the
80186 CPU [USC, IUSC]
Q: What products does the Electronic Programmer’s
Manual (EPM
™ ) support?
A: There are EPMs available for the USC and IUSC. They
can be purchased from the local Zilog Sales Office or
Zilog distributor.
Q: Should the unused pins of the (I)USC be tied High,
Low, or left floating (i.e., /TxREQ, /CTS, /DCD,...)?
A: The basic rules are: Unused OUTPUT ONLY pins can
be left unterminated. Unused INPUT ONLY pins should
be tied inactive (High if an active Low pin). Unused
I/O pins should use a pull-up (2K typical) to the inactive
state. Users often get tripped up by I/O pins because
they don’t take the time to understand when a pin is an
input and when it is an output. For example, the /SYNC
pin on the SCC family switches from input to output
when programmed for sync modes. This means that
because the SCC resets into async mode, the /SYNC
pin comes up as an input, then when WR4 is pro-
grammed, it switches to an output. Consequently,
users can fall into the trap of thinking that because they
are using it in sync mode, it is an output only—but of
course you see the problem is that until programmed,
it is an INPUT!
Q: To what level does the USC family support the Ethernet
protocol?
A: The USC family does support the frame format of
Ethernet, the 10 Mbps speed, and the Manchester
encoding/decoding used. What it does not do is:
address checking of the full 48-bit address (it only
checks 16) nor the collision detection & backoff. This
makes the USC family well suited for internetworking
applications that need the USC family’s multiprotocol
ability, since many inter-net applications (bridges &
routers) have to receive all addresses so that address
checking is not an issue. The USC family is not well
suited to applications that require the full implementa-
tion of Ethernet as is done by competitor’s chips which
only do 802.3 (no HDLC) but do support it completely.
These chips are good in LAN adaptors and worksta-
tions, but cannot do multiprotocol routing in a single
chip. Note that the USC family will be useful in so-
called “full-duplex” Ethernet and point-to-point
Ethernet, since collision detection and back-off is not
used in these cases.
UM009402-0201