
Publication#
21825
Issue Date:
July 1997
Rev:
A
Amendment/
0
This document contains information on a product under development at Advanced Micro Devices. The information
is intended to help you evaluate this product. AMD reserves the right to change or discontinue work on this proposed
product without notice.
Using 16-Bit ROMCS
Designs in élan SC300
andélanSC310 Microcontrollers
Application Note
This application note describes how to assert MCS16 for ROMCS accesses and IOCS16 for I/O
accesses without performing an external address decode.
MCS16 AND IOCS16 SIGNAL DEFINITIONS
MCS16 (memory size 16) is generated by a 16-bit
memory expansion card when the card recognizes it is
being addressed. This signal tells the data bus steering
logic that the addressed memory device is capable of
communicating over both data paths. When accessing
an 8-bit memory device, the MCS16 line remains
deasserted, indicating to the data bus steering logic
that the currently addressed device is an 8-bit memory
device capable of communicating only over the lower
data path.
IOCS16 (I/O size 16) is generated by a 16-bit ISA I/O
expansion board when the board recognizes it is being
addressed. IOCS16 provides the same function for
16-bit I/O expansion devices as the MCS16 signal
provides for 16-bit memory devices.
Note:
The élan
TM
SC300 and élanSC310 micro-
controllers internally OR together MCS16 and IOCS16.
The ORed signal is looked at by the microcontrollers on
both memory and I/O accesses (including I/O accesses
that are internal to the microcontroller).
ASSERTING MCS16 FOR ROMCS
ACCESSES WITHOUT ADDRESS DECODE
The élanSC300 and élanSC310 microcontrollers
support 16-bit wide memory in the ROMCS space. On
reset, these microcontrollers begin fetching from this
memory. The width of the ROMCS memory is
controlled by the MCS16 input. If the MCS16 signal is
asserted, ROMCS memory is treated as 16 bits wide;
otherwise, this memory will be treated as 8 bits wide.
Is there a way for a system designer to assert MCS16
for ROMCS accesses without doing an address
decode First, note that you cannot simply tie MCS16
Low, even in a system where all memory is 16 bits
wide. This does not work because the élanSC300 and
élanSC310 microcontrollers internally OR together
MCS16 and IOCS16. Thus, tying MCS16 Low will
result in all I/O accesses being incorrectly treated as 16
bits.
A better approach would be to tie ROMCS to MCS16.
MCS16 is then correctly asserted only during ROMCS
cycles. The problem with this approach is that, on
power-up, the ROMCS signal is internally gated with
MEMR and MEMW. This means that MCS16 will not be
valid until the MEMR or MEMW signal is asserted. The
timing requirements for the assertion of MCS16 during
a ROMCS cycle are basically the same as for an ISA
cycle. MCS16 must be valid 35 ns after LA is stable. If
MCS16 is gated with the MEMR or MEMW command,
it will not be valid until about 90 ns after LA.
The élanSC300 and élanSC310 microcontrollers have
a programmable option in index register B3h that
allows ROMCS to be enabled as a simple address
decode and not gated with MEMR or MEMW. Using
this option, ROMCS (and, hence, MCS16) will be
stable when SA is stable, which is 20 ns after LA is
stable, thus meeting MCS16 timing requirements.
Unfortunately, as previously noted, the élanSC300 and
élanSC310 microcontrollers power up with ROMCS
gated with MEMR, and therefore the initial code
fetches treat ROMCS as 8 bits wide. In this mode,
when fetching from a 16-bit wide memory, the
élanSC300 and élanSC310 microcontrollers will fetch
the same byte on both even and odd memory
accesses. Executing the reset code under this
restriction requires you to program index register B3h,
so that the MEMR gating can be turned off, allowing
proper 16-bit reads to occur. The code example on the
next page shows a reset code stub that meets this
requirement. In the example, all of the code fetched
before the jump to the label “fetching16” has the same
byte in the even and odd addresses. Execution starts
at the label reset_vector, which would be located at
FFFFF0.
TM