Using 16-Bit ROMCS Designs in ÉlanTMSC300 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 T M SC300 and ÉlanSC310 microcontrollers 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. 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. Publication# 21825 Rev: A Amendment/0 Issue Date: July 1997 Reset Code Example code segment assume cs: code org 0ffd7h fetching 16: ;when we reach here, we’re fetching 16 bits, ;so we can use normal instructions to jump to ;the real boot code db dw 0eah 0, 0f000h ;jmp to real start of code ;wherever that may be org 0ffdch ;must be located at 0ffdch ;this code is set up so the even and odd bytes are duplicates ;this code just puts 04B3 in ax and outputs ax to port 22h ;this sets bit 2 of index register B3, enabling ROMCS ;to be an address decode and not gated with MEMR/MEMW ;ODD EVEN db 0b4h fetching8: ;B4 duplicate of mov ah opcode ; this location must be at FFDD mov ah, 004h ;B4 04 add al, 0b0h ;B4 B0 mov al, 0b3h ;B0 B3 mov bl, 0e7h ;B3 E7 out 022h, ax ;E7 22 and ch, bl ;22 EB jmp short fetching 16 ;EB EC the fetches done at the target of this jump will be 16 bits db EC ;EC this code never gets executed so its contents do not matter ; reset vector ;EB EB jumps to FFDD harmless, sets up next instruction harmless, sets up next instruction harmless, sets up jump short instruction nop nop nop nop org 0fff0h reset_vector: jmp short fetching8 code ends end 2 Using 16-Bit ROMCS Designs in ÉlanTMSC300 and ÉlanSC310 Microcontrollers PGP PINS AS ADDRESS DECODES AND IOCS16 TIMING The general-purpose programmable PGP0 and PGP1 pins can be programmed as inputs or outputs using index register 70h bit 6 for PGP0 and index register 74h bit 2 for PGP1. PGP2 and PGP3 are output only. The PGP3–PGP0 pins can be individually programmed as decoder outputs or chip selects for external peripherals using bits 6–0 of index registers 94h for PGP2, 95h for PGP3, 9Ch for PGP1, and 89h for PGP0. In address decode mode, bits 6–0 of these registers correspond to the SA address bits SA9–SA3, which provide address decodes from 0h–3F8h in 8-byte increments. To use the PGP3–PGP0 pins to drive IOCS16, they must first be configured as address decode only in index register 91h, and then they will meet the timing in Figure 1 below. Figure 1 shows the simulation result for timing requirements for PGPx and IOCS16. For detailed timing between other signals, refer to ISA I/O 16-bit read/write cycle timing diagrams in the ÉlanTMSC300 Microcontroller Data Sheet, order #18514. SA15–SA0 t2 t1 PGPx t3 IOCS16 Notes: 1. t1: SA stable to PGP falling edge 10 ns (maximum) when programmed as address decode only (index 91h) 2. t2: SA stable to PGP rising edge 10 ns (maximum) when programmed as address decode only (index 91h) 3. t3: SA stable to IOCS16 active 95 ns (maximum) Figure 1. PGP Pins as Address Decodes Versus IOCS16 Input Timing Requirements REFERENCE MATERIAL ■ ÉlanTMSC300 Microcontroller Data Sheet, order #18514 ■ ÉlanTMSC310 Microcontroller Data Sheet, order #20668 ■ Élan TMSC300 Programmer’s Reference Manual , order #18470 ■ Élan TMSC310 Programmer’s Reference Manual, order #20665 ■ ÉlanTMSC300 and ÉlanTMSC310 Devices’ ISA Bus Anomalies Application Note, order #20747 Using 16-Bit ROMCS Designs in ÉlanTMSC300 and ÉlanSC310 Microcontrollers 3 Trademarks AMD, the AMD logo, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Élan is a trademark of Advanced Micro Devices, Inc. Product names used in this publication are for identification purposes only and may be trademarks of their respective companies. 4 Using 16-Bit ROMCS Designs in ÉlanTMSC300 and ÉlanSC310 Microcontrollers