Digital PDFs

EC-QU5KA-TE

March 1996

184 pages

Original

14MB

Document:	SA110 Evaluation Board Reference Manual 199603
Order Number:	EC-QU5KA-TE
Revision:
Pages:	184
Original Filename:	http://bitsavers.org/pdf/dec/semiconductor/arm/EC-QU5KA-TE_SA110_Evaluation_Board_Reference_Manual_199603.pdf

OCR Text

Digital Semiconductor
SA-11 OMicroprocessor
Evaluation Board
Reference Manual
Order Number: EC-QU5KA-TE

The EBSA-110 is an evaluation board for the SA-110 StrongARM®
microprocessor. This manual is the single point-of-reference for all users
of the EBSA-110. It is a configuration guide, a programmers' guide and
a technical reference.

Revision/Update Information:

Version 1.0.

March 1996
While Digital believes the information included in this publication is correct as of the date of
publication, it is subject to change without notice.
Digital Equipment Corporation makes no representations that the use of its products in the
manner described in this publication will not infringe on existing or future patent rights, nor do
the descriptions contained in this publication imply the granting of licenses to make, use, or sell
equipment or software in accordance with the description.

The following are trademarks of Digital Equipment Corporation: Digital, Digital Semiconductor and
the DIGITAL Logo.
Digital Semiconductor is a Digital Equipment Corporation business.
ABEL is a registered trademark of Data 1/0 Corporation.
Altera is a registered trademark of Altera Corporation.
ARM and StrongARM are registered trademarks of ARM Ltd.
Intel is a registered trademark of Intel Corporation.
PostScript is a registered trademark of Adobe Systems Incorporated.
Quickswitch is a registered trademark of Quality Semiconductor, Inc.
TimingDesigner is a registered trademark of Chronolgy.
VIEWlogic is a registered trademark of Viewlogic Systems Inc.
Wmdows is a trademark of Microsoft Corporation.
All other trademarks and registered trademarks are the property of their respective holders.

This document was prepared using VAX DOCUMENT, Version 2.1.

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Getting Started
1.1
Physical Description ..............................· ........... .
1.2
Handling Precautions ........................................ .
1.3
Visual Inspection ........................................... .
1.3.1
Cabling ...........................................•....
1.3.2
Links ................................................. .
1.3.3
Socketed Components .................................... .
1.3.3.1
The CPU ........................................... .
1.4
Power-On ................................................. .
1.5
Attaching the EBSA-110 to a Terminal or Host System .............. .

1-1
1-1
1-1
1-3

1-3
1-3
1-3
1-4
1-4

2 Functional Specification
2.1
2.2
2.3
2.4
2.4. 1
2.4.2
2.5
2.5.1
2.5.2
2.5.3
2.5.4
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
2.6.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14

CPU ......................................... ·.............
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voltage Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSRAM ............................................_. . . .
DRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Map Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1/0 Sub-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serial Ports and Printer Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ethernet Port and UID ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCMCIA Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Counter!l'imer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Soft 1/0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architectural Compliance Verification Facilities . . . . . . . . . . . . . . . . .
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Debug Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Endian Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
On-Board Software...........................................

2-1
2-1
2-3
2-3
2-3
2-4
2-4
2-4
2-4
2-5
2-5
2-5
2-6
2-6
2-6
2-6
2-6
2-6
2-7
2-7
2-7
2-7
2-7
2-7
2-8
2-8

iii

3 Programmers' Guide
3.1
Memory Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1
Memory Map After Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2
Characteristics of Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Memory Map Decodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1
DRAM Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2
DRAM Configuration Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3
Synchronous SRAM (SSRAM) Space . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4
EPROM/Flash Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5
I/O Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.6
RW_ABORT Space........................................
3.2.7
R_ABORT Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.8
ISAMEM Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.8.1
EBUFMEM Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.8.2
PCMCIAMEM Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.9
ISAIO Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
The PIT Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
The SuperI/O Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5
The Ethernet Controller Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6
The PCMCIA Controller Registers............... . . . . . . . . . . . . . . . .
3.7
The Soft Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8
Reset State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9
Software Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1
8-bit Accesses to Odd Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1
3-3
3-4
3-4
3-4

3-5
3-5
3-5
3-6

3-7
3-7
3-7
3-8
3-8
3-8

3-9
3-10
3-11
3-12
3-12
3-13
3-13
3-13

4 Interrupts
4.1
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.3
4.3.1
4.3.2
4.3.3
4.3.4

Distinguishing CTB_OS, CTB_ARCH Under Software Control ........ .
CTB_OS .................................................. .
The FIQ_MASK Register .................................. .
The IRQ_MASK Register .................................. .
The IRQ_MSET, IRQ_MCLR Registers ....................... .
The IRQ_RAW Register ................................... .
The IRQ_MSKD Register .................................. .
CTB_ARCH ............................................... .
The FIQ_MASK Register .................................. .
The IRQ_MASK Register .................................. .
The IRQ_CNT Cycle Counter Register ........................ .
The FIQ_CNT Cycle Counter Register ........................ .

4-2
4-2
4-2
4-3
4-3
4-4
4-4
4-4
4-4

4-5
4-5
4-6

5 Configuration of Memory and VLSI Devices
5.1
5.2
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.4
5.5
5.6
iv

Configuring Cacheable/Non-Cacheable Space ...................... .
Switching the Memory Map ................................... .
DRAM .................................................. ··
Disable Refresh Requests .................................. .
Initialize the DRAM ...................................... .
Enable Refresh Requests .................................. .
Determine the DRAl\:'.I fype ................................ .
Size the Memory ........................................ .
Test the memory ........................................ .
SSRAM ............................................ · ·. · · · ·
EPROM .................................................. .
Flash .................................................... .

5-1
5-1
5-1
5-2
5-2
5-3
5-3
5-3
5-4
5-4

5-4
5-4

5.7
5.7.1
5.7.2
5.8
5.8.1
5.8.2
5.8.3
5.8.4

5.9
5.10

PCMCIA Controller ......................................... .
Setting the PCMCIA Socket Programming Voltage .............. .
Setting a PCMCIA Socket Memory Wmdow .................... .
Ethernet Controller ......................................... .
Send the Initiation Key ................................... .
Put the Device into 'CONFIG' State .......................... .
Configure the Plug-and-play Registers ........................ .
Disable the Plug-and-play Registers ......................... .
Super 1/0 Controller ........................................ .
Programmable Interval Timer ................................. .

5-4

5-5
5-5
5-7
5-7
5-7
5-8
5-8

5-9
5-9

6 Performance
6.1
6.2
6.3
6.4
6.5
6.6
6.6.1
6.7

Synchronous SRAM Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EDO DRAM Accesses.........................................
BEDO DRAM Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance Impact of DRAM Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . .
EPROM and Flash Accesses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1/0 Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ethernet Buffer Memory Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . .
Overlap of Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-1
6-1
6-2
6-3
6-3
6-4
6-4
6-4

7 Software Development Environment
7.1
Loadable Debuggable Images .................................. .
7.1.1
Building ............................................... ·
7.1.2
Run Time Environment ................................... .
7.1.2.1
Memory Map ........................................ .
7.1.2.2
C Library Support .................................... .
7.1.2.3
Exception Vectors ..................................... .
7.1.2.4
Access to 1/0 Devices .................................. .
7.2
Standalone Flash Images ..................................... .
7.2.1
Building ............................................... .
7.2.2
Run Time Environment ................................... .
7.2.2.1
Memory Map ........................................ .
7.2.2.2
C Library Support .................................... .
7.2.2.3
Exception Vectors ..................................... .
7.2.2.4
Access to 1/0 Devices .................................. .

7-1

7-1
7-2
7-2
7-2
7-2
7-2
7-2
7-2
7-3
7-3
7-3
7-3

7-3

8 On-Board Software
8.1
8.2
8.3
8.4
8.4.1
8.4.2

The Primary Boot Loader ..................................... .
The Format of Images in Flash ................................ .
The Startup EPROM ........................................ .
Diagnostics ................................................ .
Getting Ready to Run the Diagnostics ........................ .
Description of Tests ...................................... .

8-1
8-2
8-3
8-4
8-4
8-4

9 Software Utilities
9.1
9.1.1
9.1.2
9.2
9.2.1

The Flash Management Utility ................................ .
When to Specify the Block Number .......................... .
When to Specify the 'NoBoot' Option ......................... .
The Bootp Utility ........................................... .
Variants of the bootp Program .............................. .

9-1
9-3
9-4
9-4
9-5

10 Theory of Operation
10.1
A Tour of the Schematics ..................................... .
10.1.1
Principal Buses ......................................... .
10.1.2
Power ................................................. .
10.1.3
Decoupling ............................................. .
10.1.4
Voltage Levels .......................................... .
10.1.5
Clocks ................................................ .
10.1.6
Reset ................................................. .
10.1.7
Th.e CPU .............................................. .
10.1.8
Jumpers, Etch Links, Debug Connectors and Test Points ......... .
10.1.9
SSRAM Interface ........................................ .
10.1.10
Buffering .............................................. .
10.1.11
DRAM Interface ......................................... .
10.1.12
Control Logic ........................................... .
10.1.13
EPROM/Flash .......................................... .
10.1.14
Superl/O Controller ...................................... .
10.1.15
Ethernet Controller ...................................... .
10.1.16
PCMCIA Controller ...................................... .
10.1.17
JTAG Port ............................................. .
10.1.18
Counter!l'imer .......................................... .
10.2
Control Logic .............................................. .
10.2.1
Control of CPU Bus Cycles ................................ .
10.2.2
fypes of Cycles .......................................... .
10.2.3
Sub-Block Wrapping ...................................... .
10.2.4
Th.e Burst Counter ....................................... .
10.2.5
Th.e Packer Address Counter ............................... .
10.2.6
Accesses to 16-bit Peripherals .............................. .
10.2.7
Memory Map Switching After Reset ......................... .
10.2.8
BEDO DRAM Configuration Cycles .......................... .
10.2.9
Address Decoding ........................................ .
10.2.9.1
Decoding Within the SSRAM Quadrant .................... .
10.2.9.2
Decoding Within the DRAM Quadrant ..................... .
10.2.9.3
Decoding Within the ROM Quadrant ...................... .
10.2.9.4
Decoding Within the IO Quadrant ........................ .
10.3
Timing Analysis ............................................ .
10.4
Expanding the EBSA-110 ..................................... .
10.5
The Printed Circuit Board .................................... .
10.6
Design Improvements ....................................... .

10-1
10-2
1()-3
1()-3

1D-4
1D-4
10-5
10-6
10-6
10-7
10-7
10-7
10-S
10-S
10-9
10-10
10-11
10-11
10-12
10-12
10-14
10-15
10-15
10-15
10-17
10-18
10-18
10-19
10-19
10-20
10-20
10-20
10-21
10-21
10-21
10-22
10-22

11 Simulation Waveforms
11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
11.9
11.10
11.11
11.12
11.13
11.14
11.15
11.16
11.17
11.18
11.19
11.20
11.21
11.22

automap .................................................. .
ss_wcrd .................................................. .
ss_wcwr .................................................. .
ss_rdwrap ................................................. .
ss_rdall .................................................. .
ed_wcrd .................................................. .
ed_wcwr .................................................. .
ed_rdwrap ................................................ .
bd_wcrd .................................................. .
bd_wcwr .................................................. .
bd_rdwrap ................................................ .
bd_wrf ................................................... .
rfrsh .......................................... · · · · · · · · · · · ·
cbr ...................................................... .
romrdl ................................................... .
romrd2 ................................................... .
:flashwr ................................................... .
io ....................................................... .
iordy ................................ · · · · · · · · · · · · · · · · · · · · · ·
iozws .................................................... .
iorfrdy ................................................... .
iotrick .................................................... .

11-1
11-3
11-3
11-6
11-8
11-10
11-12
11-14
11-14
11-17
11-19
11-21
11-21
11-24
11-26
11-28
11-30
11-30
11-34
11-34
11-34
11-38

A Configuration Guide
A.1
Default Configuration ....................................... .
A.2
Description of All Jumpers .................................... .
A.2.1
Supported Clock Configurations ............................. .
A.3
Description of All Links ...................................... .
A.4
Connectors ................................................ .
A.5
Debug Connectors .......................................... .
A.6
Debug Pick-up Points ........................................ .
A.7
LEDs .................................................... .
A.8
Cables Within the Enclosure .................................. .
A.8.1
Power Supply ........................................... .
A.8.2
Serial Ports ............................................ .
A.8.3
Parallel Port ........................................... .
A.8.4
Reset Switch ........................................... .
A.8.5
Turbo Switch ........................................... .
A.8.6
Loudspeaker ............................................ .
A.9
Cables for External Connection ................................ .
A.9.1
Serial Ports ............................................ .
A.9.1.1
Serial Cable for SUN Workstation ........................ .
A.9.2
Parallel Port ........................................... .
A.9.3
Parallel Port Loopback .................................... .
A.9.4
Ethernet Port ........................................... .
A.9.5
JTAG Port ............................................. .
A.10
Upgrading the DRAM SIMMs ................................. .

A-1
A-1
A-5
A-5
A-6
A-7
A-8
A-8
A-9
A-9
A-10
A-10
A-10
A-10
A-10
A-10
A-10
A-11
A-11
A-12
A-12
A-12
A-13

vii

B Debugging a Broken Board
B.1

B.2
B.3

Basic Checks .............................................. .
Checking the Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostic Failure .......................................... .

B-1
B-1
B-2

C The Design Database
D SA-110 Bus Transactor Model User's Guide
D.1
D.2
D.2.1
D.2.2
D.2.3
D.2.4
D.2.5

D.2.6
D.2.7

D.2.8
D.2.9
D.3
D.4
D.4.1
D.4.2

Instantiating the Model ...................................... .
Command Reference ........................................ .
set_addr {address} ....................................... .
set_page {offset} ......................................... .
set_bytes {byte masks}, set_size {size} ........................ .
do_rd {expected read data} ................................. .
do_crd {expected read data} ................................ .
do_wr {write data} ....................................... .
do_fwr {write data} ....................................... .
do_idle {number of cycles} ................................. .
do_swap {expected read data} {write data} ..................... .
How It Works .............................................. .
It Is Not Idiot-Proofl ........................................ .
Completeness, Known Bugs and Model Support ................ .
Porting, Modifying and Rebuilding .......................... .

D-2
D-3

D-3
D-3
D-3
D-4

D-4
D-4
D-4
D-4
D-4
D-4

D-5
D-6
D-6

E ABEL Tutorial
F Getting Started with an Uncased Board
F.0.1
F.0.2

Choosing a Power Supply .................................. .
Choosing an Enclosure .................................... .

F-1
F-1

G Technical Support and Ordering Information
Index
Figures
1-1

1-2
2-1
11-1

11-2
11-3
11-4
11-5
11-6

11-7
11-8

viii

The EBSA-110 Board ..................................... .
Position of Debug LED .................................... .
EBSA-110 Block Diagram ................................. .
automap ............................................... .
ss_wcrd ............................................... .
ss_wcwr ............................................... .
ss_rdwrap .............................................. .
ss_rdall ............................................... .
ed_wcrd ............................................... .
ed_wcwr ............................................... .
ed_rdwrap ............................................. .

1-2
1-4

2-2
11-2
11-4
11-5
11-7
·11-9
11-11
11-13
11-15

11-9
11-10
11-11
11-12
11-13
11-14
11-15
11-16
11-17
11-18
11-19
11-20
11-21
11-22
A-1

A-2

bd_wcrd ............................................... .
bd_wcwr ............................................... .
bd_rdwrap ............................................. .
bd_wrf ................................................ .
rfrsh ................................ ·. · · · · · · · · · · · · · · · · ·
cbr ................................................... .
romrdl ................................................ .
romrd2 ......................................... · · · · · · · ·
flashwr ................................................ .
io .................................................... .
iordy .................................................. .
iozws ................................................. .
iorfrdy ................................................ .
iotrick ................................................. .
EBSA-110 Configuration Links ............................. .
Position of LEDs ........................................ .

11-16
11-18
11-20
11-22
11-23
11-25
11-27
11-29
11-31
11-32
11-35
11-36
11-37
11-39

Memory Map ........................................... .
Addresses in External-Decode Space ......................... .
PIT Internal Registers ................................... .
Superl/O Registers ....................................... .
Ethernet Controller Registers .............................. .
Bit Assignment of Soft Register ............................. .
Interrupt Control Registers - CTB_OS Configuration ............ .
Interrupt Control Registers - CTB_ARCH Configuration .......... .
FIQ Mask Bit Positions ................................... .
Interrupt Mask Bit Positions - CTB_OS Configuration ........... .
FIQ Mask Bit Positions ................................... .
Interrupt Mask Bit Positions - CTB_ARCH Configuration ......... .
PCMCIA Controller Configuration Sequence ................... .
PCMCIA Programming Voltages ............................ .
Ethernet Plug-and-play Register Configuration Sequence ......... .
Ethernet Plug-and-play Register Initial Values ................. .
Stalls Added During EDO DRAM Accesses .................... .
Stalls Added During BEDO DRAM Accesses ................... .
Stalls Added During EPROM and Flash Accesses ............... .
Stalls Added During I/O Accesses ........................... .
Stalls Caused by Back-to-Back Cycles ........................ .
Boot Image Selection ..................................... .
Flash Image Header ...................................... .
Selecting Diagnostics ..................................... .
Byte/Half-Word Decode Using SAO, SBHE_L ................... .
Jumpers ............................................... .
Links ................................................. .
Connectors ............................................. .

3-1
3-9
3-10
3-10
3-11
3-12
4-1
4-1
4-2
4-3
4-4
4-5
5-4
5-5
5-8
5-8

A-2
A-9

Tables
3-1
3-2
3-3
3-4
3-5
3-6
4-1
4-2
4-3
4-4
4-5
4-6
5-1
5-2
5-3
5-4

6-1
6-2
6-3
6-4

6-5
8-1
8-2
8-3
10-1
A-1

A-2
A-3

6-2
6-2
6-4
6-4
6-5
8-1
8-3
8-4
10-18

A-3
A-5
A-6
ix

A-4
A-5

A-6
A-7

A-8
A-9
A-10
A-11

Debug Connectors ....................................... .
Pick-up point ........................................... .
Null-MoDem Cable ....................................... .
SUN Null-MoDem Cable .................................. .
Bidirectional Parallel Cable ................................ .
Parallel Port Loopback Connector ........................... .
JTAG Cable ............................................ .
Suitable DRAM SIMMs ................................... .

A-7

A-8
A-10
A-11
A-11
A-12
A-12
A-13

Preface
Introduction
The EBSA-110 is an evaluation board for Digital Semiconductor's SA-110
microprocessor. It is designed to meet the following requirements:
•

To provide a power-on vehicle for the SA-110 chip.

•

To provide an environment in which to run the ARM® architectural
compliance software test suite.

•

To provide a non-proprietary example design.

•

To provide a software development environment, including a fast memory
sub-system on which to run software benchmarks.

This document is a single point-of-reference both for configuring and using the
board and for engineers wishing to copy parts of its design. As such, it has the
following scope:
•

Functional specification

•

Theory of operation (to be read in conjunction with the circuit schematics)

•

Configuration guide (memory options, speed options, jumper and link options)

•

Programmers' guide (memory maps, boot process, references to programmble
I/O devices on the board)

This document does not aim to duplicate material to be found elsewhere.
Specifically, it does not duplicate material that is to be found in vendor data
sheets for components used in the design, nor does it document the ARM software
development environment.

How to Use This Document
All readers should turn to Chapter 1 for information about how to connect and
power-on the board, how to verify that it is working correctly and how to connect
it to a terminal or host system.
All readers are advised to read Chapter 2 to get an understanding of the overall
functionality of the board. Subsequent chapters assume a familiarity with the
material in this chapter.
Thereafter, software engineers will probably want to refer to the following
chapters:
•

Chapter 3 is a guide to the memory map of the board and the address
decoding of all I/O devices.

•

Chapter 4 describes the interrupt structures.

•

Chapter 5 is a guide to configuration of the memory and VLSI devices on the
board.

•

Chapter 7 is a brief introduction to the software development environment.

•

Chapter 8 describes the on-board software, including the. power-on sequence
of the board, and the power-on diagnostics.

•

Chapter 9 describes software utilities which are provided with the EBSA-110.

•

Chapter 6 contains performance-related information, and documents the cycle
times required for accessing various devices on the board.

Hardware engineers will probably want to refer to the following chapters:
•

Chapter 10 is a detailed technical description of the hardware of the board,
including a theory of operation.

•

Chapter 11 describes a number of simulation waveforms, giving a deeper
insight into the operation of the EBSA-110 control state machines.

A number of appendices provide general reference material:
•

Appendix A describes all of the link and jumper options present on the board,
and all of the cables that may be required for connection to the board.

•

Appendix B provides hints on how to track down faults on the EBSA-110.

•

Appendix C describes the machine-readable design databases for the
EBSA-110 hardware and software.

•

Appendix D describes the operation and usage of the SA-110 Bus Transaction
Model, which is provided as part of the design database.

•

Appendix E is a brief tutorial in the ABEL® PLD synthesis language used to
describe the state machines in the EBSA-110 design.

•

Appendix F describes how to choose a suitable enclosure and power supply for
the board.

•

Appendix G describes other relevant documents and services that are
available from Digital and its partners.

Notation
All numbers are shown in decimal unless otherwise stated.
All hexadecimal numbers have an Ox prefix. 32-bit hex values have dots for ease
of reading. Examples are: OxfeOb.3004, O:xfb.
All binary number have an Ob prefix; long numbers include dots for ease of
reading. Examples are: ObOO, Ob0000.0000.1010.0000.
This document refers to an 8-bit data unit as a byte, a 16-bit data unit as a
half-word and a 32-bit data unit as a longword. t
This document uses the notation INTn to refer to a naturally-aligned block of n
bytes. Thus, an INT4 is an aligned 32-bit value whilst an INT32 is eight 32-bit
values on a naturally aligned address (this corresponds to the size and alignment
of an SA-110 cache block).

t Standard ARM notation is to use the terms byte, half-word and word, respectively.
Digital's convention is to use the terms byte, word and longword. Therefore, this
document avoids use of the term 'word', which is ambiguous to different audiences.

xii

Electrical signal names are shown thus: cpu_wait_l. An _I at the end of a signal
name indicates that the signal is asserted (active) when it is low (close to OV).

References
This section provides a selective bibliography and a reference to relevant
manufacturers' data sheets. ARM-specific and SA-110-specific information is
referenced in Appendix G.
1. SSRAM: Micron MT58LC32K36C4-LG (or MT58LC32K36D7-LG) data sheet.
2. PCMCIA controller: VADEM VG-468 PC Card Sock.et Controller Data
Manual (December 1993, Rev 02, or later). VADEM, San Jose, CA. Tel +1 408
943-9301. Fax +1 408 943-9735. UK distributor: MMD. Tel +44 1734 633700.
3. Super 1/0: PC87312 data sheet, National Semiconductor Corporation.
4. EDO DRAM: Micron MT16D232M-6 X DRAM Module data sheet.
5. Burst EDO DRAM: Micron MT4D232M-6 ES DRAM Module data sheet.
6. Flash ROM: 28F008SA data sheet, Intel order number 290429-004.
7. EPLD: EPM7096LC84-7, Altera 1995 Data Book.
8. Ethernet controller: Advanced Micro Devices Am79C961A data sheet (AMD
publication number 19364 Rev. A (October 1994) with Amendment sheet 1)
9. High-Speed Digital Design - a handbook of black magic. (Howard W Johnson,
Martin Graham, 1993 Prentice Hall ISBN 0-13-395724-1).

xiii

1
Getting Started
The EBSA-110 is provided built, tested and cased. This chapter provides a
physical description of the board and then describes how to:
1. Perform a visual inspection of the EBSA-110.

2. Power-on the EBSA-110 for the :first time.
3. Attach the EBSA-110 to a terminal or host system.
If you wish to use a different enclosure for the board, refer to Appendix F for
details on choosing a suitable power supply and enclosure.

1.1 Physical Description
The EBSA-110 is shown in Figure 1-1. It is a single-board computer designed
to match the form-factor of a baby-AT PC motherboard. This allows it to be
mounted in a standard desktop or deskside PC cabinet. Flying leads connect the
board to its 110 connectors. The 110 connectors are mounted in break-out holes
that are standard on these systems. The board is powered from the cabinet's
power supply using the standard PC power connectors.

1.2 Handling Precautions
The EBSA-110 contains components that are susceptible to permanent damage
from electrostatic discharge ('static' electricity). Risk of damage can be alleviated
by following a few simple handling precautions.
If the EBSA-110 was supplied cased and you remove the cover, ensure that the
case is earthed and that you are wearing an antistatic wrist strap before making
any adjustments to the board.
If the EBSA-110 is supplied as a bare board, it is supplied in an antistatic bag.
Do not remove the board from the bag unless you are working on an antistatic
earthed surface and wearing an antistatic wrist strap. Always adopt these
precautions when handling the board.

1.3 Visual Inspection
When you receive your unit, you should perform these minimum checks:
•

Inspect the enclosure for physical damage.

•

Check the power supply line input voltage is correct for your geography.

Even if your EBSA-110 was provided as a cased unit, you may still want to take
the lid off and perform the following checks:
•

Internal cables fully attached

Getting Started 1-1

Getting Started
1.3 Visual Inspection
Figure 1-1 The EBSA-110 Board

®
I-

UHll

...

--...
o=
-... ~

..
-: ~·

.. ... ...

D-

u 11!9 u

tBI

...

:11111

OCl

:::

...

...... --"""'...

-G
-

~ I-

1-2 Getting Started

:::

(h!§I

Getting Started
1.3 Visual Inspection
•

Links attached and correctly set

•

Socketed components properly seated

More details are provided below for this second set of checks.

1.3.1 Cabling
Identify each of the cables and ensure that it is correctly polarized and fully
mated to the appropriate connector on the board:
•

Power connectors: There are two 6-way power connectors. The 4 black cables
align with the connector pins marked 'GND' on the board.

•

Reset cable: This 2-way cable can be connected either way around. The board
connector is marked 'RESET'.

•

COMl cable: This is a ribbon cable with pin 1 marked by a colored stripe.
The board connector is marked 'COMl' and pin 1 is marked by a 'l' and a
pointer.

•

COM2 cable: This is identical to the COMl cable. The board connector is
marked 'COM2' and pin 1 is marked by a '1' and a pointer.

•

LPT cable: This is a ribbon cable with pin 1 marked by a colored stripe. The
board connector is marked 'LPTl' and pin 1 is marked by a 'l' and a pointer.

Refer to Appendix A if you cannot identify the connectors.

1.3.2 Links
Verify that all jumpers are pushed fully down on their mounting posts.
If any jumpers have come off or you are unsure about their positions, refer to
Section A 1 for a description of the default settings.

1.3.3 Socketed Components
Verify that any socketed devices (the programmable devices, the DRAM SIMMs
and the EPROM (if fitted}) are fully mated in their sockets.
1.3.3.1 The CPU

The EBSA-110 is designed so that the CPU can be soldered directly to the board,
or fitted in a socket. Some boards have the CPU fitted in a socket. Do not tamper
with the socket or remove the CPU unless you have a good reason to. The CPU
is removed by pressing down on the socket frame that surrounds the CPU, then
lifting the CPU out using a vacuum pencil. In the absence of a vacuum pencil,
you can use something sticky on the blunt end of a pencil. Take care not to bend
any CPU leg during this process, as it may result in an intermittent electrical
contact when you replace the CPU.

-----------------------~ Note --------------------------~
The CPU socket is not polarized. When viewing the EBSA-110 so that the
CPU is in the bottom right-hand comer of the board, the CPU is correctly
orientated when its pin 1 (marked by a circle) is in the bottom left-hand
corner of the chip.

Getting Started 1-3

Getting Started
1.4 Power-On

1.4 Power-On
The initial test of the board should be performed with no cables attached to the
system, apart from the power cable. Make a note of the jumpers fitted (if any) to
J2 pins 9-10, 11-12, 13-14, 15-16. Remove any jumpers from these pins. This will
force the board to execute its start-up software and then enter the ARM remote
debug stub.
There are a group of 5 LEDs on the rear of the unit. Use Figure 1-2 to identify
the 'debug' LED. Watch this LED as you power-on the board The LED should be
off whilst the board is reset, then on for about 0.5s whilst the ARM remote debug
stub initializes, then tum off and remain off.
Now attach a terminal or terminal emulator to the COMl port on the EBSA-110.
The terminal should be configured for 9600 baud, 8-bit data, 1 stop bit, no parity,
no flow control. After you reset or power-cycle the system, you should see a
message like this on the terminal:
ARMalOO, DEMON Vl.l, Ox40020000 bytes RAM, ROM CRC OK, Little endian

If the system fails to behave as described, or you wish to perform more thorough

testing of the system, run the system diagnostics using the procedure described
in Section 8.4. If the system behaves correctly, read on.
Figure 1-2 Position of Debug LED

Red

"Debug"

LED

xilxxGxxllxx§xxllx
1.5 Attaching the EBSA-110 to a Terminal or Host System
When the EBSA-110 is used as a software development system, it is directly
connected to a host system. The host system may be either a PC or a workstation.
In either case, connection can be made in one of the following ways:
•

Using a serial port
In this configuration, a cable connects the COM! port on the EBSA-110 to the
host system. The debug environment uses the serial link as a bidirectional
link for commands and responses, and to download images from the host to
the EBSA-110.

•

Using the Ethernet t

t The Ethernet option is not supported in the initial release of the software.
1-4 Getting Started

Getting Started
1.5 Attaching the EBSA-110 to a Terminal or Host System
In this configuration, the EBSA-110 and the host system are both connected
to an Ethernet LAN. The debug environment uses the LAN as a bidirectional
link for commands and responses and to download images from the host to
the EBSA-110.
Refer to Chapter 7 for more information on the software development
environment.
When the EBSA-110 is running its power-on diagnostics, status and progress
information are written to the COMl port. The COMl port should be connected
to a terminal or terminal emulator configured for 9600 baud, 8-bit data, 1 stop
bit, no parity, no :flow control.
Refer to Chapter 8 for more information on the diagnostics.
If the EBSA-110 is used for some standalone application, that application may
control all interfaces on the board. Refer to Section 7.2 for information on
building standalone applications.
Refer to Section A.9 for details of the cables required in all these configurations.

Getting Started 1-5

2
Functional Specification
This chapter describes each functional element of the EBSA-110. More detailed
information describing how the board works and how to program it can be found
in later chapters of this document. Figure 2-1 is a· block diagram of the board.

2.1 CPU
The EBSA-110 uses the SA-110 microprocessor. The board allows the CPU to be
operated at any of its 16 core clock frequencies (between 88.3 MHz and 287.0
MHz with the upper limit determined by the speed grade of the CPU that is
fitted) and either of its two core voltages (+l.5V or +2.0V). You can set the core
voltage and frequency using jumpers on the board.
The EBSA-110 uses the SA-110 pin-bus in the following modes:
•

Synchronous bus mode (SA-110 generates the bus clock)

•

Enhanced bus mode (cache wrapping and write buffer merging)

•

Fastbus mode (delayed address timing)

For special applications, these modes can be changed by rewiring etch links on
the board. Refer to Section A3.
The CPU is packaged in a 144-pin thin quad fl.at-pack (TQFP). The EBSA-110
provides a dual-footprint layout to allow the CPU to be surface-mounted or to be
fitted in a socket.

2.2 Clocks
The EBSA-110 uses the following oscillators:
•

3.6864 MHz (baud-rate) oscillator for the SA-110. The oscillator is a standard
surface-mounted (SMT) part with a TTL output and it relies on an external
level converter to generate the +3.3V switching levels that are required by
the CPU. The CPU uses an internal phase-locked loop (PLL) to generate its
core clock from this clock.

•

24.0 MHz oscillator for the Superl/O controller. This is an SMT part with a
TTL output.

•

20.0 MHz crystal for the Ethernet controller. This is a 2-pin through-hole
part. The Ethernet controller contains the circuitry to bias this crystal into
oscillation.

Functional Specification 2-1

::!!
ca
c

~
::J

Block ·aiagram
(!'111'1'141
f!111'1'1"1)

,. ,,,,,
__

·1•11·.

Qsi,

0 -·
()
0

m
en

1•nc:k~i·

. - - - - - - - - . u1-:1-·n.r-~n11. _lotl-:U

vc; ··ltirt
u:~

u:1ct1•1-,1~

'•·I

(Hll'l'l.O)

l\M'/!IC•Hil/\

••nUI 1·nl •~~•·

(Sll'l'l l )

(!;ll'l'l~i)

!".1:.u<:xn

(!'..;ll'J"131

U>.•ll

/ll•

UUl"'_f\

c·r:;h:E~J:ff~~ili~r~J.

O::'l'H•• PAKJ\•

I I '-

r.•rn_ro
RIX>E ·:
t
CTl\_lU=Wl\OB
CTD_ .1~1'1.'l'W•.• '

r---------

!>V do1n••Jn

L-----1 - - - - - - - -

-3; :;;ll;i~ - - - - - - -.

ISlt'l'GJ

r::~y~nmrnnblo

cu11•r10J
CTA_hUP'U_WROF!_J,
CTA_UUl-'D_RDOE_t.
CTA_UUFD_WRO••I
c-1•A_nu1-·o_RD01_1

r.vT

(SllTOI

l.evol

ohi£t
'32

I.VT

DUF.•l>

AllT

l.ftVGl

'32

CPU_A

DRAM

f!:Y~mnrnnblct

SIMM

ohif't

(SllTOI

C:Hl'1'31
(SHT71

SS HAM

(&UT6)

32KM32

(SJIT51

a
c;·

;II\"

;

ltlll•" •• A

1.v·1·

g
ca

l:Jll'l'llll

loVAl
__..i-_nl1lf1:.

Di'

CSHT7)

Crook

:r'"""
c

All'I"

f i

'0"""

:-.JIJl•l.:1<1"0
.,.1111:1'#111•·•

(n11·1•1101

N::::S

Cil

.N c"11

CD
()

::;:

c;·

Functional Specification
2.2 Clocks
The SA-110 generates complementary output clocks mclk, nm.elk by dividing
down its core clock. The EBSA-110 is designed to run with a maximum mclk
frequency of 55 MHz, and this corresponds to core clock divisors of between 2 and
5. nm.elk is used to clock the on-board state machines and control logic.
Control logic on the board uses nm.elk to generate a divided-by-seven clock
(approximately 6 MHz) which is used in the J/O sub-system to clock the
programmable interval timer and the PCMCIA controller.
All clocks have a low fanout, so no external clock buffering is used.

2.3 Reset
A power-on reset is generated from an RC network and schm.itt trigger
arrangement. A 2-pole 0.1" pitch connector is provided to allow an external
normally-open reset switch to be attached. In a lab environment, you can
generate reset by shorting these poles with a screwdriver or jumper.

2.4 Power
The EBSA-110 has the following power requirements:
•

+5V +/- 5%, @ 1 Amp for the main logic

•

+12V +/- 5%,@ 0.5 Amp for the Flash and PCMCIA sockets

The board will function without the +12V supply, with the restrictions that it
will not be possible to program the Flash memory, and that there will be no
+12V power available for plug-in PCMCIA cards t. If your power supply does not
supply +12V, the +12V supply rail should be left disconnected.
Several devices on the board require +3.3V and this is generated from +5V using
an adjustable linear regulator.
The CPU core requires +l.5V or +2.0V (depending upon the core clock frequency).
This is generated from +3.3V using an adjustable linear regulator. You can select
the regulator output using a jumper.

2.4.1 Voltage Domains
The SA-110 outputs use +3.3V switching levels, and the inputs are not +5Vtolerant (they cannot withsta:r;id +5V TTL switching levels). The gynchronous
SRAM's outputs use +3.3V switching levels, but the inputs are +5V-tolerant. All
the remaining devices on the board are +5V-tolerant.
The following interfacing techniques are used on the board:
•

74LVT devices are used as voltage converters. These parts have a +3.3V
supply and are +5V-tolerant. Their output switching range is within the TTL
switching threshold and so they can drive TTL-level devices powered from
+SV. 74LVT devices are used as interfaces on the CPU address and data
buses.

•

Output signals from +3.3V devices can be used to drive TTL-level inputs
directly. This method is used to interface SA-110 outputs to the system
control logic.

t This is most likely to affect PCMCIA disk drives and Flash cards.
Functional Specification 2-3

Functionai Specification
2.4 Power
•

Quality Semiconductor 'QuickSwitch®' devices are used as voltage converters.
These devices perform voltage conversion with 'zero' (actually, around 250ps)
delay. These parts are used to interface clocks and system control logic
outputs to SA-110 inputs.

2.4.2 Power Sequencing
The SA-110 requires two voltage supplies; a +3.3V supply to powers its primary
input/output buffers (the pin bus) and a +l.5V or +2.0V supply to power its core.
The +3.3V supply must become stable earlier than the core voltage supply. This
requirement prevents any possibility of latch-up within parasitic structures on
the SA-110. This requirement is satisfied on the EBSA-110 by deriving the +2.0V
supply from the +3.3V supply, rather than directly from the +5.0V supply.
There are no other power-sequencing requirements.

2.5 Memory
The EBSA-110 provides three distinct memory regions:
•

ROM: non-volatile storage for programs

•

SSRAM: fast memory for time-critical code and data

•

DRAM: for large code and data sets

2.5.1 ROM
Non-volatile storage for the bootstrap program is provided in an EPROM
(512Kbyte) or a Flash ROM (1024Kbyte). Both are 8-bit devices. They are
mapped into different regions of the memory map. A user-configurable jumper
determines which of them is decoded at address 0 (and therefore supplies the
reset vector to the CPU after reset). Normally, the Flash ROM would be used,
and the EPROM (which is socketed) would not be fitted. The EPROM is provided
for manufacturing use and as insurance against the user unwittingly deleting the
primary bootstrap image from the Flash.
CPU reads from the ROM are automatically packed to provide INT4s to the CPU.
This is achieved by a state sequence that reads four consecutive bytes from the
ROM in response to the CPU access. This packing is transparent to the CPU,
and does not affect the format or ordering of data programmed into the ROM.
During CPU writes, consecutive locations in the Flash are sparsely addressed.
The mapping is described in Section 3.2.4.
CPU reads from the ROM can be sequential or non-sequential cycles.
CPU writes to the Flash (to program it) must be non-sequential cycles.

2.5.2 SSRAM
A region of fast RAM is implemented using a single 32Kx32 synchronous static
RAM (SSRAM) device. This provides 128Kbytes. Alternatively, the circuit-board
footprint for the SSRAM can accommodate the 64Kx36 device, when it becomes
available. This memory region should be used for speed-critical code and data,
when possible.

2-4 Functional Specification

Functional Specification
2.5 Memory
2.5.3 DRAM
Two 72-pin 5V DRAM memory SIMMs can be fitted. The DRAM memory
controller supports Extended Data Out (EDO) and Burst EDO (BEDO) parts with
an access time of 60ns or better. The first generation of BEDO parts are available
as 2Mx32 SIMMs, so two SIMMs provide a total of 16Mbytes of DRAM.
The memory controller uses the ID signals from a DRAM SIMM to automatically
accommodate SIMMs of various sizes.
The memory controller is soft-configurable between EDO and BEDO operation,
and the bootstrap software automatically determines the memory type during the
power-on sequence.
If two SIMMs are fitted, they must be of the same size and type.

The DRAMs are periodically refreshed using a CAS-before-RAS sequence. The
refresh sequence is initiated by a timer which is initialized by the bootstrap
software during the power-on sequence.
The DRAM controller is simple-minded in two ways:
•

It will always satisfy the RAS precharge time between a pair of accesses, even
if the accesses are to separate physical banks of DRAM.

•

It does not interleave (neither between banks in a SIMM nor between SIMMs)

Sequential cycles from the CPU are always performed as page-mode DRAM
accesses and conversely, the DRAM controller will always terminate a page mode
cycle when the CPU terminates its sequential access (it does not speculatively
keep the page open).

2.5.4 Memory Map Switching
Immediately after reset, the CPU fetches its reset vector from address 0. During
normal operation, it is preferable to have RAM at address 0. The EBSA-110
control logic allows the memory map to be switched to accommodate these
requirements. The process is described in Section 3.1.1.

2.6 1/0 Sub-System
All I/O on the EBSA-110 is performed as programmed I/O under the control of the
CPU. The I/O sub-system provides the following resources:
•

2 RS232 serial ports with PC-style 9-way D-connectors

•

1 bidirectional PC-style parallel printer port with 25-way D-connector

•

Ethernet port with lOBaseT (twisted pair) media support on an RJ45 jack
connector

•

Ethernet Unique ID ROM

•

PCMCIA controller

•

3-channel counter/timer

•

Soft-programmable outputs

•

Soft-readable inputs

•

Architectural compliance verification facilities

Functional Specification 2-5

Functional Specification
2.6 1/0 Sub-System
2.6.1 Serial Ports and Printer Port
The serial and parallel ports are implemented using a National Semiconductor
PC87312 SuperI/O III chip. This part also includes a floppy disk controller and
decodes for an IDE interface but these functions are not used in this design.

2.6.2 Ethernet Port and UID ROM
The Ethernet port is implemented using a National Semiconductor Am.79C961A
'ISA-net' controller operated in shared-memory mode. The UID ROM is accessed
via the AM79C960. In shared-memory mode, the Am79C961A uses external RAM
as temporary data storage. This external RAM is attached to the Am 79C961A
and is accessible to the CPU via the Am.79C961A.
The Ethernet port only supports the lOBaseT (UTP) media. lOBaseT requires a
hub-based topology but can also be used point-to-point between two nodes.

2.6.3 PCMCIA Controller
Two PCMCIA sockets are supported, using a Vadem VG468 controller. Socket A
is the socket closer to the board. Both socket A and socket B can support Type I,
II and III PCMCIA cards. A Type III card in Socket A will mechanically obscure
Socket B, preventing it from being used.

2.6.4 Counter!Timer
The counter/timer is implemented using an Intel® 82C54 Programmable Interval
Timer (PIT). The PIT is a three-channel device. One channel is dedicated to
producing a periodic signal for the memory controller in order to initiate DRAM
refresh. The other two channels are available for application software; their
timeout outputs can be used to generate interrupts to the CPU.

2.6.5 Soft 1/0
The soft I/O is implemented within programmble logic. There are 4 read/write
outputs (the written value can be read back by the CPU) and 4 read-only inputs.
These signals are used to control various on-board functions, including an LED.
The bits are described in Section 3. 7.

2.6.6 Architectural Compliance Verification Facilities
The programmable control logic implements some facilities which are used for
architectural verification. This functionality duplicates facilities that exist in the
silicon development environment for the SA-110. These facilities are:
•

The ability to generate ABORTs to the CPU on certain read and write cycles.

•

The ability to generate interrupts as the result of a timeout on a
programmable down-counter that has been loaded by the CPU and then
decremented at the rate of the system bus clock.

These facilities are described in more detail in Section 3.2.6, Section 3.2. 7 and
Chapter 4.
These facilities are not required during normal operation and the resources that
they use within the programmble logic are reassigned to provide an interrupt
controller.

2-6 Functional Specification

Functional Specification
2. 7 Interrupts

2. 7 Interrupts
The EBSA-110 includes a simple interrupt controller that can be used to support
re-entrant interrupts and lowest-latency 'priority levels' on the fl.at interrupt
structure that the single IRQ interrupt provides. The interrupt controller is
described in Chapter 4.

2.8 JTAG
A 7x2 header is fitted to provide electrical access to the EBSA-110 JTAG port.
The SA-110 only provides boundary scan access.

2.9 Hardware Debug Support
The EBSA-110 provides connectors and test points to make it easy to attach a
logic analyzer to the board. The pickups are of two types:
•

The buffered address and data buses and some other low-speed signals are
routed to 16-pin 2x8 header plugs. These are suitable for direct connection
to a Tektronix DAS logic state analyzer and can be connected to any other
analyzer using 'grabber' probes.

•

Various control signals have etch vias on their routing to allow a Harwin post
to be soldered into the board. This allows a logic analyzer to be attached,
but does not interfere with the high-speed signals by adding additional etch
length and capacitance.

As always, the additional load imposed by test equipment may interfere with the
normal operation of the board.

2.1 O Expansion
The EBSA-110 has no standard expansion capability. However, the control
signals present on the debug connectors are sufficient to allow 1/0 devices to be
interfaced via a mezzanine PCB. This is discussed in Section 10.4.

2.11 Control Logic
All of the control logic for the CPU, memory and 1/0 sub-systems is implemented
within two 84-pin PLCC programmable logic parts. The source files for these
parts are provided as part of the design database, allowing you to modify them if
required.
The control logic is described in detail in Section 10.2.

2.12 Endian Issues
The SA-110 can be configured as a little-endian or a big-endian machine t. The

t The terms 'little-endian' and 'big-endian' have been adopted by the computer industry
to describe the way in which bytes are ordered within larger data units. Machines
which treat the byte on the low-order data bus lines (the byte with the lowest address)
as the least-significant byte are termed 'little-endian'. Machines which use the opposite
ordering (most-significant byte at the lowest address) are termed 'big-endian'. The
VAX is a little-endian machine, as is the Intel x86 family. The Motorola 68xx family
is big-endian. Most modern RISC implementations are ambi-endian; they can be
configured to run with either endian-ness. The term 'endian' comes from Jonathan
Swift's "Gulliver's Travels". The two great empires of Lilliput and Blefuscu were engaged
in a most obstinate war as the result of an edict published by the Emperor of Lilliput.
In this edict, the Emperor did command "all his subjects, upon great penalties, to break
the smaller end of their eggs". Many hundred large volumes have been published upon
this controversy: but the books of the Big-Endians have been long forbidden. Swift's
Functional Specification 2-7

Functional Specification
2.12 Endian Issues
recommended mode of operation is little-endian, and this is the default state after
reset. The EBSA-110 can be operated with either endian-ness, with no impact on
the hardware. The on-board software is configured for little-endian operation. If
big-endian operation is required, the following changes must be made:
•

The definitions of all I/O addresses must be changed. For example, a bytewide I/O device at address 0 on a little-endian machine will be at address 3
on a big-endian machine.

•

The byte ordering within the ROM must be changed; the ROM packer
hardware (refer to Section 2.5.1) packs bytes from the ROM into a littleendian order, so a big-endian image must be pre-scrambled to compensate
(the alternative is to redesign the packer sequencer in the control logic).

2.13 LEDs
The EBSA-110 has 4 LEDs, which are used to provide information on the
status of the Ethernet link, and a further 1 LED that is used to provide debug
information. Section A. 7 describes the LEDs.

2.14 On-Board Software
The EBSA-110 on-board software is programmed into the Flash ROM. The Flash
can contain a number of independent images. At a minimum, the Flash contains
a program called the Primary Bootstrap Loader (PBL). The PBL can load and
start a specified image stored in Flash. By default, it starts up the ARM remote
debugger stub. A power-on diagnostic suite is also programmed into the Flash
and can be selected by changing jumpers on the board.

invention was a satire on the Spanish war of succession and a commentary on the history
of religious controversy in England. The analogy to computer byte ordering is poor.
Whilst it is true "That all true believers shall break their eggs at the convenient end",
(in other words, endian-ness in egg consumption is irrelevant) the relative endian-ness
of a pair of computers can be important when they want to exchange data.
2-8 Functional Specification

3
Programmers' Guide
This chapter is a reference for programmers. It describes the memory map of the
board, the reset state of the system and software programming restrictions.

3.1 Memory Map
The SA-110 has a 32-bit address bus with byte addressability and a 32-bit data
bus. The address space is divided into quadrants based on A[31:30] and devices
have multiple aliases in each quadrant.
An overview of the memory map is shown below:

+------------------+

I/0

+------------------+

I
I
I

A[31:30]

I
I
I

+------------------+ [1,1)

EPROM/FLASH

+------------------+

+------------------+ [1,0]

I Synchronous SRA.J.! I

I Synchronous SRAM I

+------------------+
EPROM/FLASH

I
I
I

+------------------+
(After reset)

+------------------+ [0,1)
DRAM

I
I
I

+------------------+ [0,0]
(Normal operation)

A full table of addresses within the memory space is shown in Table 3-1.
Section 3.2 describes how the memory space is decoded.
Table 3-1

Memory Map

Address

Name

Function

Oxffif.ffff

ISAIO_END

Last location in ISAIO space

Oxf3c0.0000

TRICK7

Interrupt control

Oxf380.0000
Oxf340.0000

TRICK6
TRICK5

Interrupt control

Oxf300.0000
Oxf2c0.0000

TRICK4

Interrupt control
Interrupt control

TRICKS

Interrupt control

(continued on next page)

Programmers' Guide 3-1

Programmers' Guide
3.1 Memory Map
Table 3-1 (Cont.) Memory Map
Address

Name

Function

Oxf280.0000

TRICK2

Interrupt control

Oxf240.0000

TRICK!
PIT_CTLW

Soft registers

Oxf200.000d

Control Word register

Oxf200.0009

PIT_CNT2

Counter 2 register

Oxf200.0005

PIT_CNTl

Counter 1 register

Oxf200.0001

PIT_CNTO

Counter 0 register

Oxf200.0000

TRICKO

PIT registers base

Oxf200.0000
Oxf000.0000

ISAIO_EDBASE
(free)

This area is free for other ISAIO stuff

Oxf000.14fl

PNP_WRDATA

Plug-and-play Auto-Configuration writedata port (write-only)

OxfOOO.Offc

SIO_COMlEND

Last SuperI/O COMl register

OxfOOO.OfeO

SIO_COMlBASE

Start of SuperI/O COMl registers

Oxf000.0e64

SIO_DATA

SuperI/O (configuration) data register

Oxf000.0e60

SIO_INDEX

SuperI/O (configuration) index register

OxfOOO.Odfc

SIO_LPT2END

Last SuperI/O LPT2 register

OxfOOO.OdeO

SIO_LPT2BASE

Start of SuperI/O LPT2 registers

OxfOOO.Obfc
OxfOOO.ObeO

SIO_COM2END

Last SuperI/O COM2 register

SIO_COM2BASE

Start of Superl/O COMl registers

Oxf000.07cl

PCMCIA_DATA

PCMCIA controller Data register

Oxf000.07c0

PCMCIA_INDEX

PCMCIA controller Index register

Oxf000.04fl

PNP_ADDRESS

Plug-and-play Auto-Configuration address
port (write-only)

Oxf000.046c

NET_IDP

ISACSR register data port

Oxf000.0468
Oxf000.0464

NET_RESET
NET_RAP

Reset the controller
Register address port (shared by RDP and
IDP)

Oxf000.0460
Oxf000.0440

NET_RDP
NET_UID

Oxf000.0405

PNP_RDDATA

Plug-and-play Auto-Configuration readdata port (read-only)

Oxf000.0000

ISAIO_SDBASE

Start of self-decode ISAIO space

Oxf000.0000

ISAIO_BASE

Start of ISAIO space

Oxefff.ffff
Oxea00.0000

ISAMEM_END
(free)

Last location in ISAMEM space
This area is free for other ISAMEM
allocation

Oxe9ff.ffff

PCMCIAMEM_END

Last location in PCMCIA reserved space

Oxe800.0000

PCMCIAMEM_BASE

Oxe7ff.ffff

EBUFMEM_ALIASE

Start of PCMCIA reserved space
End of last Ethernet buffer memory alias
(continued on next page)

3-2 Programmers' Guide

Start of external-decode ISAIO space

Programmers' Guide
3.1 Memory Map
Table 3-1 (Cont.) Memory Map
Address

Name

Function

OxeOO 1.ffif

EBUFMEM_END

Last location of Ethernet buffer memory

Oxe000.0000

EBUFMEM_BASE

Start of Ethernet buffer memory

Oxe000.0000

ISAMEM_BASE

Start of ISAMEM space

Oxdfif.ffif

RW_ABORT_END

Last location in Read/Write-Abort space

Oxd000.0000

RW_ABORT_BASE

Start of Read/Write-Abort space

Oxcfff.ffif

R_ABORT_END

Last location in Read-Abort space

Oxc000.0000

R_ABORT_BASE

Start of Read-Abort space

Ox8fff.ffif

ROM_ALIASE

End oflast ROM alias

Oxa007 .ffif

EPROM_END

Last location in EPROM memory

Oxa000.0000

EPROM_BASE

Start in EPROM memory

Ox800f.ffif

FLASH_END

Last location in Flash memory

Ox8000.0000

FLASH_BASE

Start of Flash memory

Ox7fff.ffif

SSRAM_ALIASE

End of last SSRAM alias

Ox4002.0000

SSRAM_ALIASS

Start of first SSRAM alias

Ox4001.ffif

SSRAM_END

Last location of SSRAM memory

Ox4000.0000

SSRAM_BASE

Start of SSRAM memory

Ox3fff.ffif

DRAM_ALIASE

End oflast DRAM alias

OxOOff.ffff

DRAM_16M

End of first 16Mbytes of DRAM

OxOObf.ffif

DRAM_12M

End of first 12Mbytes of DRAM

Ox007f.ffif

DRAM_8M

End of first 8Mbytes of DRAM

Ox003f.ffif

DRAM_4M

Endoffirst4MbytesofDRAM

Ox0000.0000

DRAM_BASE

Start of DRAM memory

3.1.1 Memory Map After Reset
After reset, the SA-110 fetches its reset vector from address 0. Therefore, it is
necessary to have ROM at this address immediately after reset. This is achieved
by decoding the EPROM/Flash in two quadrants immediately after reset. The
memory map is switched under software control. The first write performed by
the SA-110 (after reset) will switch the memory map to normal operation. The
memory map switch occurs afier the write cycle completes. Therefore, if the write
is to address 0, the data will not be written to the DRAM, but will be written
to EPROM/Flash space (that is, the write will be ignored t ). If two writes to
address 0 are performed, the second will successfully write data to the DRAM.
Due to the very low performance of ROM accesses (each 32-bit access is performed
by packing data from 4 successive locations in the 8-bit ROM) the image to be
executed should normally be copied into RAM first. Before starting a copy, the
software should jump to the high-order alias of the ROM and switch the address
map.
It is not possible to reverse this address map switching process under software·
control.

t The Flash ROM is sensitive to writes; that is how it is given commands and programmed.
However, each of the commands requires a pair of bus cycles with specific (different)
data so this switching mechanism is safe.

Programmers' Guide 3-3

Programmers' Guide
3.1 Memory Map
3.1.2 Characteristics of Memory
The SSRAM is small and fast (factor of 1), the DRAM is large and quite fast
(factor of 1/2 - 1/3), the EPROM/Flash is very slow (factor of 1116).
Because of the slow speed of the EPROM/Flash access, is is best to copy images
from EPROM/Flash into SSRAM or DRAM and execute them from there.

3.2 Memory Map Decodes
This section describes how the memory space is decoded. It provides essentially
the same information as Table 3-1, but in a greater level of detail.
The diagrams in the following sections use this key:
0 - must be 0
1 - must be 1
A - significant to address a location within device
a - significant to address optional locations within device (eg alternative
memory size)
X - don't-care: significant to address aliases within device
- - not available (Al, AO represent byte lanes on the 32-bit bus)

3.2.1 DRAM Space
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
1 0 9 8 7 6 5 4 3 2 1 0 9 B7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 Xx x XX xx xx xx xx x Xx Xx Xx xx xx xx x X - -I
+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX XX XX X 0 A A A A A A A A A A A A A A A A A A A A - -I (B)EDO 1Mx32 SIMO
+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX XX XX X 1 A A A A A A A A A A A A A A A A A A A A - -I (B}EDO 1Mx32 SIMl
+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX X X XX 0 A A A A A A A A A A A A A A A A A A A A A - -I (B}EDO 2Mx32 SIMO
+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX XX XX 1 A A A A A A A A A A A A A A A A A A A A A - -I (B}EDO 2Mx32 SIMl
+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX XX X 0 A A A A A A A A A A A A A A A A A A A A A A - -I BEDO 4Mx32 SIMO
+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX XX X 1 A A A A A A A A A A A A A A A A A A A A A A - -I BEDO 4Mx32 SIMl
+-------+-------+-------+-------+-------+-------+-------+---+---+
This decodes the DRAM. Zero, one or two DRAM SIMMs may be fitted. They
must be 72-pin +5V types, either x32 or x36. The hardware automatically detects
and accommodates 1Mx32, 2Mx32 and 4Mx32 SIMMs. This means that the board
can accommodate up to 32Mbytes of DRAM. The DRAM controller can support
EDO and BEDO parts. If two SIMMs are fitted, they must be the same size and
type. The memory is contiguous and byte addressable. There are multiple aliases
of the DRAM in the system address space. The hardware reads all bytes of a
longword during reads, and performs byte masks during writes.
The DRAM is not accessible immediately after reset (see Section 3.1.1).

3-4 Programmers' Guide

Programmers' Guide
3.2 Memory Map Decodes
3.2.2 DRAM Configuration Space
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
1 0 9 87 6 54 3 21 0 9 87 6 54 3 2 1 0 9 87 6 5 4 3 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX X A A A A AX XX XX XX XX XX X DD DD DD DD - -I DCBR=l
+-------+-------+-------+-------+-------+-------+-------+---+---+
When BEDO DRAMs are :fitted, a special pair of cycles, CBR (CAS-before-RAS)
and WCBR (write CAS-before-RAS), must be performed in order to configure the
DRAMs. EDO DRAMs require no configuration.
These cycles are performed by setting the DCBR (do CAS-before-RAS) bit in the
Soft register and then performing read and write cycles to the normal DRAM
space.
When performing these configuration cycles, the data written is irrelevant;
the value on the low-order address lines configures the DRAMs. The following
addresses should be used:
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 A AAAA AAAA A
1 0 9 87 6 54 3 2 1 0 9 87 6 5 4 3 2 1 0 9 87 6 5 4 3 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
10 0 XX X A A A A AX XX XX XX XX XX X 0 0 1 0 0 0 0 0 - -I DCBR=l
+-------+-------+-------+-------+-------+-------+-------+---+---+
The effect of this write is to set the BEDO DRAM burst ordering to 'linear'.
After performing the write (or all writes) a read should be performed to the same
address. This restores the DRAM to normal operation. After all CBR and WCBR
cycles have been completed, the DCBR bit should be cleared.
The configuration process is described in detail in Section 5.3.

3.2.3 Synchronous SRAM (SSRAM) Space
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 A AAAA AAAA A
1 0 9 87 6 54 3 2 1 0 9 87 6 5 4 32 1 0 9 87 6 5 4 3 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
10 1 XX XX XX XX XX XX a A A A A A A A A A A A A A A A - -I
+-------+-------+-------+-------+-------+-------+-------+---+---+
This decodes the synchronous SRAM (SSRAM). There are multiple aliases. The
SSRAM is contiguous and byte addressable. The hardware reads all bytes of a
longword during reads, and performs byte masks during writes. The SSRAM is
either 128Kbyte or 256Kbyte. 128Kbyte is the normal size.

3.2.4 EPROM/Flash Space
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 A AAAAAAAA A
1 0 9 B7 6 5 4 3 2 1 0 9 B7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
11 0 s XX xx Xx XX xx xx xx xx x Xx xx XX XX Xx - -I
+-------+-------+-------+-------+-------+-------+-------+---+---+

ID 0 S XX XX XX XX XX XX XX XX XX XX XX XX XX X - -I (at reset)

+-------+-------+-------+------~+-------+-------+-------+---+---+

10 0 0 XX XX X b b XX A A A A A A A A A A A A A A A A A A - -I (Flash)

+-------+-------+-------+-------+-------+-------+-------+---+---+

10 0 1 XX XX XX XX XX A A A A A A A A A A A A A A A A A - -I (EPROM)

+-------+-------+-------+-------+-------+-------+-------+---+---+

Programmers' Guide 3-5

Programmers' Guide
3.2 Memory Map Decodes
This decodes the EPROM/Flash. In norm.al operation, S=O decodes the Flash,
and 8=1 decodes the EPROM. Therefore, the Flash will be decoded at address
0 after reset and so the system will boot from Flash. If the jumper EPROM_
BOOT is fitted, the behavior of S is inverted, and so the system will boot from
EPROM. Usually, there is no need to fit the EPROM. The EPROM socket and
EPROM_BOOT facility are provided for manufacturing and as an 'emergency
repair' mechanism in case the Flash is programmed with a bad image.
The EPROM is a 512Kbyte device, and is read-only. The Flash is a lMbyte device
and is readable and sector writeable. Refer to the manufacturer's data sheet for
programming details.
Since the EPROM and the Flash are byte-wide devices, they are accessed via a
packer mechanism which assembles a 32-bit data unit from an aligned address.
This is transparent to the software during reads, but affects the way in which
byte accesses are performed when writing to the Flash.
When writing to the Flash, the data must always be supplied on the low-order
byte .Jane. This corresponds to byte writes to addresses 0, 4, 8 and so on. The
actual byte addressability is provided by the address lines marked 'b' above.
Therefore, the first 9 byte locations in Flash are addressed as:
Ox0000.0000
Ox0040.0000
OxOOB0.0000
OxOOc0.0000
Ox0000.0004
Ox0040.0004
OxOOB0.0004
OxOOc0.0004
Ox0000.0008

Writes to the Flash are always performed as non-sequential cycles, so the Flash
must not be placed in cacheable space during programming and the write buffer
must not be used for writes to the Flash.

3.2.5 1/0 Space
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAA AAAAAA
1 0 9 87 654 3 2 1 0987 6 54 321 0987 65 43 21 0

+-------+-------+~------+-------+-------+-------+-------+---+---+

il 1 0 l XX XX XX XX XX XX XX XX XX XX XX XX XX - -I RW_ABORT

+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 0 0 XX XX XX XX XX XX XX XX XX XX XX XX XX - -I R_ABORT
+-------+-------+-------+-------+-------+-------+-------+---+---+

All devices in the I/O space quadrant are 8-bit or 16-bit devices and are physically
attached to one or both of the two low-order byte lanes of the data bus. Since the
data bus is actually 32-bits wide, addresses in I/O space are not contiguous.
Byte masks are only partially decoded in this space and so writes to incorrect
addresses are more likely to corrupt a device than to be ignored.
In a little-endian system, all valid byte addresses in this space end in ObOO or
ObOl, and all valid half-word addresses end in ObOO.

3-6 Programmers' Guide

Programmers' Guide
3.2 Memory Map Decodes
The I/O space quadrant is further subdivided into quadrants:
•

ISAI0 space

•

ISAMEM space

•

RW_ABORT space

•

R_ABORT space

3.2.6 RW_ABORT Space
The RW_ABORT space is an architectural compliance verification facility; it is
unlikely to be useful in normal applications.
Any reads or writes within this· address range will result in an abort exception.
Sequential cycles to this address space will result in an abort exception for each
data beat of the sequential cycle.
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
1 0 9 87 65 43 21 09 87 6 5 4 3 2 1 098 7 6 54 3 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 x XX XX XX XX x XX XX XX XX XX x XX XX XX X - -I IO quadrant
+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 0 1 XX XX XX XX XX XX XX XX XX XX XX XX XX - -I RW_ABORT
+-------+-------+-------+-------+-------+-------+-------+---+---+
3.2.7 R_ABORT Space
The R_ABORT space is an architectural compliance verification facility; it is
unlikely to be useful in normal applications.
Any reads within this space will result in an abort exception. Writes will be
ignored. Sequential writes to this address space will be ignored. Sequential reads
to this address space will result in an abort exception for each data beat of the
sequential cycle.
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
1 0 9 8 7 65 4 3 2 1 0 987 6 5 4 3 2 1 0 98 7 65 43 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 XX XX XX XX XX XX XX XX XX XX XX XX XX XX - -I IO quadrant
+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 0 0 XX XX XX XX XX XX XX XX XX XX XX XX XX - -I R_ABORT
+-------+-------+-------+-------+-------+-------+-------+---+---+
3.2.8 ISAMEM Space
The ISAMEM space is used to access devices which behave like ISA-bus memory
devices. This includes PCMCIA card resources (accessed through the PCMCIA
controller) and the Ethernet controller's buffer memory.
The address ranges occupied by PCMCIA card resources and the Ethernet
controller are software configurable.
Cycles in ISAMEM space are controlled using memr_l, memw_l, zws_l and rdy.

Programmers' Guide 3-7

Programmers' Guide
3.2 Memory Map Decodes
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
1 0 987 65 4 3 21 09876 543 21 0987 65432 1 0

The Ethernet controller maintains transmit and receive data structures in a piece
of shared memory. This memory is decoded within the ISAMEM space in the
address range where a[27]=0, that is:
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
1 0 987 65 4 3 21 0 987 6543 21 09 87 654321 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 1 0 0 XX XX XX XX XX A A A A A A A A A A A A A A A - -I EBUFMEM
+-------+-------+-------+-------+-------+-------+-------+---+---+
The EBUFMEM is accessed using byte and half-word read/writes. It appears in
the address space as 16-bit memory and so its locations are non-contiguous.
The algorithm to convert an offset a in EBUFMEM space into an address is:
address = (a & 1) I ( (a & Oxffff. fffe) « 1) I OxeOOO. 0000
3.2.8.2 PCMCIAMEM Space

Resources on PCMCIA cards are accessed by configuring the PCMCIA controller
to open windows in the ISAMEM space. The addresses must be selected to fall
into an address range where a[27]=1 t, that is:
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
1 0 987 65 4 3 21 0987 654 321 0987 6 5432 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 1 0 1 XX A A A A A A A A A A A A A A A A A A A A A A A - -I PCMCIAMEM
+-------+-------+-------+-------+-------+-------+-------+---+---+
Refer to Section 5. 7.2 for a worked example of setting a PCMCIA window.
The PCMCIAMEM is accessed using byte and half-word read/writes. It appears
in the address space as 16-bit memory and so its locations are non-contiguous.
The algorithm to convert an offset a in PCMCIAMEM space into an address is:
address = (a & 1J I ((a & Oxffff. fffe) « 1) I OxeOOO. 0000

3.2.9 ISAIO Space
The ISAIO space is used to access devices which behave like ISA-bus I/O devices.
This includes the PIT, the Soft I/O register, the interrupt control registers,
the SuperI/O registers, the PCMCIA internal control registers, PCMCIA card
resources (accessed through the PCMCIA controller) and some of the Ethernet
controller registers.
The address ranges occupied by PCMCIA card resources and the Ethernet
controller are software configurable.
t There is no hardware checking of this restriction, because the PCMCIA controller cannot
decode a[27]. If you try to map memory into the area of ISAMEM space where a[271=0,
you will cause bus contention with the EBUFMEM area.

3-8 Programmers' Guide

Programmers' Guide
3.2 Memory Map Decodes
Cycles in ISAIO space are controlled using ior_l, iow_l, zws_l and rdy.
AAAAAAAAAAAAAAAAAAAAAA
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 AAAAAAAAAA
l 0 9 8 7 6 5 4 32 l 0 98 7 6 5 4 3 21 0 9 8 7 6 5 4 3 2 1 0

+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 1 1 XX XX XX XX XX XX XX XX XX XX XX XX XX - -I ISAIO
+-------+-------+-------+-------+-------+-------+-------+---+---+
11 l 1 1 XX 0 XX XX XX XX XX XX X A A A A A A A A A A - -I self-decode
+-------+-------+-------+-------+-------+-------+-------+---+---+
11 1 l l XX 1 A A AX XX XX XX XX XX XX XX XX XX X - -I external-decode
+-------+-------+-------+-------+-------+-------+-------+---+---+
The ISAIO space is divided into two regions:
•

The first region is for ISA-like devices that decode their own addresses based
on the expectation that the whole 110 space is limited to a 10-bit decode (1/0
addresses O-Ox3FF). a[25]=0 is used to select these devices.

•

The second region is for devices that require external address decode logic.

The following devices sit in self-decoding space:
•

Superl/O controller

•

Ethernet controller

•

PCMCIA controller (including resources on PCMCIA cards)

The following devices sit in external-decode space:
•

PIT

•

Soft register

•

Interrupt control registers

These devices are further decoded using a[24:22]. The addresses of these
registers are shown in Table 3-2. For more information on the PIT, soft register
and interrupt control registers, refer to Section 3.3, Section 3. 7 and Chapter 4.
Table 3-2 Addresses in External-Decode Space
Address

Name

Function

Oxf3c0.0000

TRICK7

Interrupt control

Oxf380.0000
Oxf340.0000

TRICK6
TRICK5

Interrupt control
Interrupt control

Oxf300.0000

TRICK4

Interrupt control

Oxf2c0.0000

TRICK3

Interrupt control

Oxf280.0000
Oxf240.0000

TRICK2
TRICKl

Interrupt control

Oxf200.0000

TRICKO

PIT registers

Soft registers

3.3 The PIT Registers
The Programmable Interval Timer (PIT) is an Intel 82C54. It is physically
attached to bits 15:8 of the data bus.

Programmers' Guide 3-9

Programmers' Guide
3.3 The PIT Registers
The PIT has three timer channels. All are clocked by ctb_clkby7, which has a
nominal frequency of 7.6 MHz. Channel 0 is used to provide a refresh request for
the DRAM; its configuration is described in Section 5.3. Channels 1 and 2 are
uncommitted, and may be used to generate interrupts to the CPU.
The PIT is decoded in external-decode ISAIO space. It has 4 memory-mapped
registers which are accessed by byte read/writes to the addresses shown in
Table 3-3.
Table 3-3 PIT Internal Registers
Address

Name

Oxf200.000d

Control WorCJ. register

Oxf200.0009

Counter 2 register

Oxf200.0005

Counter 1 register

Oxf200.0001

Counter 0 register

3.4 The Superl/O Registers
The Superl/O controller is a National Semiconductor PC87312. It is physically
attached to bits 7:0 of the data bus.
The Superl/O controller has 4 groups of registers which are decoded in selfdecoding ISAIO space. It is accessed using byte read/writes to the addesses
shown in Table 3-4.
Table 3-4 Superl/O Registers
Port Address

ISAIO Address

Name

Function

Ox03f8

OxroOO.OfeO

COMl

COMlUARTbaseaddre~

Ox02f8

OxroOO.ObeO

COM2

COM2 UART base address

Ox0378

OxfOOO.OdeO

LPT2

LPT2 printer port base address

Ox0398

OxfOOO.Oe60

INDEX

Configuration index register
address

Ox0399

Oxro00.0e64

DATA

Configuration data register
address

The positions of these registers are software configurable, but you are
recommended to leave them at their power-on defaults.
For the Superl/O controller, use this algorithm to convert an 1/0 address, a, into
an ISAIO address:
ISAIO_address = (a << 2) I Oxf000.0000
'take the port address, left shift by 2 bits then OR with Oxf000.0000'

For programming information, refer to the manufacturer's data sheet.

3-10 Programmers' Guide

Programmers' Guide
3.5 The Ethernet Controller Registers

3.5 The Ethernet Controller Registers
The Ethernet controller is an AMD Am.79C961A. It is physically attached to bits
15:0 of the data bus.
The Ethernet controller is decoded in self-decoding ISAIO space. It has 2 groups
of registers which are accessed by byte and half-word read/writes:
•

3 Auto-Configuration registers. These registers are used to access indirectly
the Plug-and-play (PNP) configuration registers.

•

Access registers. These registers are used to access directly the Unique ID
(UID) PROM and to access indirectly the internal resources of the Ethernet
controller.

The register addresses are shown in Table 3-5.
Table 3-5 Ethernet Controller Registers
Port Address

ISAIO Address

Name

Function

Ox0279

Oxf000.04fl.

PNP_ADDRESS

Ox0a79

Oxf000.14fl.

PNP_WRDATA

Ox0203

Oxf000.0405

PNP_RDDATA

Ox0220

Oxf000.0440

NET_UID

Ox0230
Ox0232

Oxf000.0460
Oxf000.0464

NET_RDP
NET_RAP

Ox0234
Ox0236

Oxf000.0468
Oxf000.046c

NET_RESET
NET_IDP

Plug-and-play AutoConfiguration address port
(write-only)
Plug-and-play AutoConfiguration write-data port
(write-only)
Plug-and-play AutoConfiguration read-data port
(read-only)
Ethernet UID address PROM
(16 bytes)
Register data port
Register address port (shared by
RDPandIDP)
Reset the controller
ISACSR register data port

The positions of the registers are software configurable, and must be configured
after reset using the process described in Section 5.8. The addresses shown
assume that the default values in Section 5.8 are used.
The addresses shown in this table assume that 16-bit I/O is used to access
the registers. If 8-bit 110 is used, registers at odd addresses must be accessed
using longword stores and loads. For the Ethernet controller, this affects the
plug-and-play registers during configuration. Refer to Section 3.9.1 for details.
This is the algorithm used to convert a memory address, a, to an ISAMEM
address:
ISAMEM_address = (a & 1) I ((a & Oxffff. fffe) «

1) I Oxe000.0000

This is the algorithm used to convert an I/O address, a, into an ISAIO address:
ISAIO_address = (a & 1) I ((a & Oxffff. fffe) «

1) I OxfOOO. ODDO

For programming information, refer to the manufacturer's data sheet.

Programmers' Guide 3-11

Programmers' Guide
3.6 The PCMCIA Controller Registers

3.6 The PCMCIA Controller Registers
The PCMCIA controller is a Vadem VG-468. It is register-compatible with the
Intel 82365SL. It is physically attached to bits 15:0 of the data bus.
The PCMCIA controller has two internal registers which are decoded in selfdecoding ISAIO space. They are accessed by byte read/writes to the addresses
shown below:
•

The Index register is at port address Ox03e0, corresponding to ISAIO address
Oxf000.07c0.

•

The Data register is at port address Ox03el, corresponding to ISAIO address
Oxf000.07cl.

The position of these registers is software configurable, but you are recommended
to leave them at their power-on defaults.
PCMCIA cards plugged into the controller will require address space allocation
in ISAMEM and/or ISAIO space. Addresses are allocated under software control,
and must be selected so that they do not clash with any other devices in the
system. Once a device has been allocated space, it can be accessed by byte and
word read/writes.
The addresses shown above assume that 16-bit 110 is used to access the registers.
If 8-bit 110 is used, registers at odd addresses must be accessed using longword
stores and loads. For the PCMCIA controller, this affects all accesses to the data
register. Refer to Section 3.9.1 for details.
For programming information, refer to the manufacturer's data sheet.

3.7 The Soft Register
The Soft register is used for board configuration and control. This register is
accessed by byte reads and writes to address Oxf240.0000. All output bits are
automatically reset to 0 after reset or power-on. The bit assignment of this
register is shown in Table 3-6.
Table 3-6 Bit Assignment of Soft Register
Bit

Name

Type

Description

LED_L

Read/Write

Write a 0 to illuminate the red 'debug' LED, write a 1
to extinguish it.

SPKR

Read/Write

Write a 1 to this bit to enable the speaker output.
When this bit is set, the speaker is driven from the
output of PIT channel 1. This facility is only available
when using CTB_OS. The state of this bit does not
affect the ability of the PIT channel 1 to generate
interrupts.

DCBR

Read/Write

Write a 1 to this bit so that accesses to DRAM space
are performed as CAS-before-RAS cycles; used for
DRAM configuration only. This bit must only be set
when the refresh counter is disabled.

BURST

Read/Write

Write a 1 to this bit when the system is fitted with
BEDODRAMs.
(continued on next page)

3-12 Programmers' Guide

Programmers' Guide
3. 7 The Soft Register
Table 3-6 (Cont.) Bit Assignment of Soft Register
Bit

Name

Type

Description

JMP15

Read-only

When read as a 'O', indicates that a jumper is fitted
on J4 pins 15-16. Writes are don't care. This jumper
is unassigned by on-board software and can be used
by application software.

JMP13

Read-only

When read as a 'O', indicates that a jumper is fitted
on J4 pins 13-14. Writes are don't care. This jumper
is used by the PBL.

JMPll

Read-only

When read as 'O', indicates that a jumper is fitted on
J4 pins 11-12. Writes are don't care. This jumper is
used by the PBL.

JMP09

Read-only

When read as 'O', indicates that a jumper is fitted on
J4 pins 9-10. Writes are don't care. This jumper is
used by the PBL.

3.8 Reset State
When the EBSA-110 is held in reset, the SA-110 PLL stops. During this time, the
external state machines and the PIT will not be clocked. Therefore, the contents
of DRAM will be UNKNOWN after reset.
Since the EBSA-110 can be reset asynchronously with respect to CPU bus
activity, it is possible that a reset will also corrupt the contents of the SSRAM.

3.9 Software Restrictions
The EBSA-110 does not support sequential cycles (store multiple or load multiple)
into I/O space or ROM/Flash space. The only exeception to this is the abort space,
which does support sequential cycles.

3.9.1 8-bit Accesses to Odd Addresses
A problem occurs in some peripherals (or some registers within peripherals)
which are only designed to accommodate 8-bit I/O cycles. For these accesses, the
peripheral expects to transfer data on the low-order byte lane, byte lane 0. If the
register address is even, this will work correctly. However, if the register address
is odd, the CPU will expect to transfer data on byte lane 1.
The EBSA-110 supports 16-bit I/O to all devices. In 16-bit I/O, data is transferred
on the natural byte lane. You can perform 16-bit I/O by using LDB/STB and
LDH/STH instructions (8-bit and 16-bit loads and stores).
The EBSA-110 provides hardware support which also allows 8-bit I/Oto odd
register addresses in the Ethernet and PCMCIA controllers. You can perform
8-bit I/O cycles to odd addresses by using LD/ST instructions (32-bit loads and
stores) to an address that is rounded down from the odd address. The significant
data is presented in the low byte of the 32-bit data. On reads, the high-order
bytes must be masked off under software control.
Accesses to even addresses are always achieved using LDB/STB and LDH/STH
instructions; there is no difference between 8-bit I/O and 16-bit I/O in this case.

Programmers' Guide 3-13

Programmers' Guide
·3.9 Software Restrictions
For example:

PCMCIA controller is accessed via index register {at Dx3EDJ and data
register (at Ox3E1J. The data register is at an odd address so
it must be accessed using the 8-bit I/O trick.
PCMCIA_INDEX16
EQU Dxf00007c0 ,, for 16-bit I/Oto index register
PCMCIA_DATAS
EQU Oxf00007cl ii this is what it would be ..
PCMCIA_DATA16
EQU Oxf00007c0 ii for 8-bit I/Oto data register
LDR rO, =PCMCIA_INDEX16
LDR rl, =PCMCIA_DATAS
MOV r2, Oxff
MOV r3, Ox03
STB r3, [rO)
; ; select register 3 (write to INDEX}
MOV r4, Ox47
, , set register to 47 (write to DATA}
ST r4, [rl)
LDB rs, [rO)
, , can check this directly
CMP rS, r3
LD rS, [rl)
AND rS, rs, r2
CMP rS, r4
; ; had to mask before comparing
ii
ii
ii

In practice, 8-bit 110 cycles are only required for configuring the Ethernet
controller and configuring the PCMCIA controller and so the overhead introduced
by the masking process is minimal.

3-14 Programmers' Guide

4
Interrupts
The SA-110 has two interrupt inputs: irq (interrupt request) and :6.q (fast
interrupt request). The EBSA-110 provides software-programmable interrupt
control logic to route interrupts from 1/0 devices to one or other of the two CPU
interrupt inputs.
There are two different configurations for the interrupt control logic. The :first,
referred to as CTB_OS, is optimized for the implementation of operating-system
software on the EBSA-110. The second, referred to as CTB_ARCH, is optimized
for architectural compliance verification of the SA-110 processor. These two
configurations can be distinguished under software control.
Most systems use the CTB_OS configuration. The configuration is reported when
the power-on diagnostics are run.
An EBSA-110 can be configured for one or other version by changing a single,
socketed, programmable logic device.

This chapter concentrates on the CTB_OS configuration and then discusses the
CTB_ARCH in terms of its differences from the CTB_OS configuration.
Table 4-1 shows the registers available in the CTB_OS configuration. Table 4-2
shows the registers available in the CTB_ARCH configuration.
Table 4-1 Interrupt Control Registers - CTB_OS Configuration
Address

Name

Read Function

Write Function

Ox:f280.0000
Ox:f2c0.0000
OxIB00.0000
Oxf340.0000
Oxf380.0000

TRICK2
TRICK.3
TRICK4
TRICK.5
TRICK6
TRICK7

reserved
IRQ_MASK
IRQ_MSKD

FIQ_MASK
IRQ_MSET
IRQ_MCLR
reserved
reserved
reserved

OxIBc0.0000

IRQ_RAW
reserved
reserved

Table4-2 Interrupt Control Registers - CTB_ARCH Configuration
Address

Name

Read Function

Write Function

Ox:f280.0000
Ox:f2c0.0000
OxIB00.0000
Oxf340.0000

TRICK2
TRICK.3

reserved

FIQ_MASK
IRQ_MASK

TRICK4
TRICK5

reserved
reserved

reserved

reserved
reserved
(continued on next page)

Interrupts 4-1

Interrupts

Table 4-2 (Cont.) Interrupt Control Registers - CTB_ARCH Configuration
Address

Name

Read Function

Write Function

Oxf380.0000

TRICK6

reserved

FIQ_CNT

Oxf3c0.0000

TRICK7

reserved

IRQ_CNT

4.1 Distinguishing CTB_OS, CTB_ARCH Under Software Control
Software can distinguish the CTB_ARCH and the CTB_OS configurations using
this sequence:
1. Write Oxff to the TRICK4 register.
2.

Write Ox55 to the TRICK3 register.

3. Write OxOO to the TRICK3 registert.
After this sequence of accesses, a read from the TRICK3 register will return Ox55
for a CTB_OS configuration, and OxOO:j: for a CTB_ARCH configuration.

4.2 CTB_OS
The CTB_OS configuration is designed for normal software applications. It
provides an interrupt controller designed for use by an operating system.
For IRQ, the functionality meets the requirements of the ARM "Reference
Microcontroller" specification. For FIQ, somewhat simpler functionality is
provided.
The CTB_OS configuration is intended to allow independent device drivers to
support re-entrant interrupts and lowest-latency 'priority levels' on the fiat
interrupt structure that the single irq interrupt provides.
The CTB_OS configuration also provides a write-only mask register that allows
any combination of interrupts to be routed to the SA-110 fiq input.

4.2.1 The FIQ_MASK Register
The FIQ_MASK register is write-only and is used to control which interrupt
sources can generate an interrupt on FIQ. This register is accessed by byte
writes. The bit assignment of this register is shown in Table 4-3. In all cases,
writing a 'l' enables the interrupt source.
Table 4-3 FIQ Mask Bit Positions
Bit

Function

USER_IRQ interrupt

PCMCIA socket A interrupt ORt PCMCIA socket B interrupt

"fThis is a Boolean OR operation; the interrupt is asserted if either PCMCIA socket is generating an
interrupt.

(continued on next page)

t The final step of writing OxOO is important. Without this step, the data bus could remain
charged with the Ox55 data, giving a misleading result on the final step.
In the implementation of the CTB_ARCH device, the data bus will turn on for the read,
but no register will be selected because the IRQ_MASK is write-only, therefore the bus
will be driven with 0.

4-2 Interrupts

Interrupts
4.2 CTB_OS
Table 4-3 (Cont.) FIQ Mask Bit Positions
Bit

Function

PIT channel 2 interrupt

PIT channel 1 interrupt

3
2

Ethernet interrupt
COM2 interrupt

COMl interrupt

LPTl interrupt

The reset state of FIQ_MASK is UNKNOWN so a write of OxOO is required to put
the mask into a known state.

4.2.2 The IRQ_MASK Register
This register is read-only (but is at the same address as a write-only register)
and allows software to determine what interrupt sources are currently enabled.
This register is accessed by byte reads. The bit assignment of this register is
shown in Table 4-4. In all cases, reading a '1' indicates that the interrupt source
is enabled.
Interrupt sources are enabled and disabled using the IRQ_MSET and IRQ_MCLR
registers.
Table 4-4 Interrupt Mask Bit Positions - CTB_OS Configuration
Bit

Function

USER_IRQ interrupt

6
5

PCMCIA socket A interrupt ORt PCMCIA socket B interrupt
PIT channel 2 interrupt

4
3

PIT channel 1 interrupt
Ethernet interrupt

COM2 interrupt

COMl interrupt

LPTl interrupt

tThis is a Boolean OR operation; the interrupt is asserted if either PCMCIA socket is generating an
interrupt.

4.2.3 The IRQ_MSET, IRQ_MCLR Registers
These two write-only registers allow bits in the IRQ_MASK register to be set and
cleared. A byte write to IRQ_MSET will enable any interrupt source which has
a 'l' in its bit position. No other interrupt sources are affected. A byte write to
IRQ_MCLR will disable any interrupt source which has a '1' in its bit position.
No other interrupt sources are affected. These two registers allow interrupt
sources to be enabled and disabled independently without the controlling software
needing to know the current state of the interrupt mask. The bit assignments for
writes to these registers are identical to those for the CTB_OS configuration of
IRQ_MASK (shown in Table 4-4).
The current state of the interrupt mask can be read from IRQ_MASK

Interrupts 4-3

Interrupts
4.2CTB_OS
The reset state of IRQ_:MASK is UNKNOWN so a write of Oxff to IRQ_MCLR is
required to put it into a known state (OxOO).

4.2.4 The IRQ_RAW Register
The IRQ_RAW register is read-only and is accessed by byte reads. The IRQ_RAW
register returns the unmasked state of the interrupt sources. A 'l' indicates that
the associated interrupt is asserted. The bit assignments are identical to those
for the CTB_OS configuration ofIRQ_:MASK (shown in Table 4-4).
All interrupt sources are synchronized to provide data for the IRQ_RAW
register. When the CPU starts a read from IRQ_RAW register the state of the
synchromzed interrupt sources is frozen until the read cycle has completed. This
prevents the CPU from reading changing data (which would have indeterminate
results).

4.2.5 The IRQ_MSKD Register
The IRQ_MSKD register is read-only and is accessed by byte reads. The IRQ_
MSKD register shows which enabled interrupt sources are asserting an interrupt.
A 'l' indicates that the associated interrupt is both asserted and enabled. The bit
assignments are identical to those for the CTB_OS configuration of IRQ_:MASK
(shown in Table 4-4). If the value of IRQ_MSKD is non-zero, the IRQ interrupt
will be asserted at the CPU.

4.3 CTB_ARCH
The CTB_ARCH configuration is designed for architectural compliance
verification testing. It provides a method of generating interrupts to the
CPU under software control, using counters that are clocked at the CPU bus
frequency.
The CTB_ARCH configuration provides a pair of write-only mask registers. One
of these allows any combination of interrupts to be routed to the SA-110 irq
input, and the other provides the same function for the fiq inputs.
The CTB_ARCH configuration does not provide the facility to read the current
state of the interrupts or interrupt masks.

4.3.1 The FIQ_MASK Register
The FIQ_MASK register is write-only and is used to control which interrupt
sources can generate an interrupt on FIQ. This register is accessed by byte
writes. The bit assignment of this register is shown in Table 4-5. In all cases,
writing a 'l' enables the interrupt source.
The only difference between the CTB_ARCH and CTB_OS implementations of the
FIQ_MASK register is the assignment of bit 7.
Table 4-5 FIQ Mask Bit Positions
Bit

Function

FIQ_CNT cycle counter interrupt
(continued on next page)

4-4 Interrupts

Interrupts
4.3 CTB_ARCH
Table 4-5 (Cont.) FIQ Mask Bit Positions
Bit

Function

6
5
4
3
2
1
0

PCMCIA socket A interrupt ORt PCMCIA socket B interrupt
PIT channel 2 interrupt
PIT channel 1 interrupt
Ethernet interrupt
COM2 interrupt
COMl interrupt
LPTl interrupt

tThis is a Boolean OR operation; the interrupt is asserted if either PCMCIA socket is generating an
interrupt.

The reset state of FIQ_MASK is UNKNOWN so a write of OxOO is required to put
the mask into a known state.

4.3.2 The IRQ_MASK Register
This register is write-only and behaves in the same way as the FIQ_MASK
register. The only difference is the assignment of bit 7. This register is accessed
by byte writes. It is used to control which interrupt sources can generate an
interrupt on IRQ. This register is accessed by byte writes. The bit assignment
of this register is shown in Table 4-6. In all cases, writing a 'l' enables the
interrupt source.
Table 4-6 Interrupt Mask Bit Positions - CTB_ARCH Configuration
Bit

Function

IRQ_CNT cycle counter interrupt

6
5
4
3
2
1
0

PCMCIA socket A interrupt ORt PCMCIA socket B interrupt
PIT channel 2 interrupt
PIT channel 1 interrupt
Ethernet interrupt
COM2 interrupt
COMl interrupt
LPTl interrupt

tThis is a Boolean OR operation; the interrupt is asserted if either PCMCIA socket is generating an
interrupt.

The reset state of IRQ_MASK is UNKNOWN so a write of OxOO is required to put
the mask into a known state.

4.3.3 The IRQ_CNT Cycle Counter Register
The IRQ cycle counter register is write-only and is used to generate an interrupt
after a certain number of bus clock (mclk) cycles. This register is accessed by
byte writes. When a value of 0-0xfe is written to the register, it is decremented to
0 at a rate of one per mclk. When it reaches 0, it generates an interrupt on IRQ
(provided its mask bit is set). On the next mclk, the counter decrements from
0 to Oxff, and remains at Oxff. The timer interrupt is cleared by a write to the
IRQ_MASK register with D7=1.
Interrupts 4-5

Interrupts
4.3 CTB_ARCH
The reset state of the counter is UNKNOWN so a write of OxOO is required to
initialize the counter before using it for the first time.

4.3.4 The FIQ_CNT Cycle Counter Register
The FIQ cycle counter register is write-only and is used to generate an interrupt
after a certain number of bus clock (mclk) cycles. This register is accessed by
byte writes. When a value of 0-0xfe is written to the register, it is decremented to
0 at a rate of one per mclk. When it reaches 0, it generates an interrupt on FIQ
(provided its mask bit is set). On the next mclk, the counter decrements from 0
to Oxff, and remains at Oxff. The timer interrupt is cleared by a write to the FIQ
Mask register with 07=1.
The reset state of the counter is UNKNOWN so a write of OxOO is required to
initialize the counter before using it for the first time.

4-6 Interrupts

5
Configuration of Memory and VLSI Devices
Software must perform a number of tasks to initialize the hardware. This section
provides some guidelines on configuring the memory and VLSI devices on the
board.

5.1 Configuring Cacheable/Non-Cacheable Space
In order to enable the CPU D-cache and write-buffer you must enable the MMU.
The page-tables used by the MMU can control, on a page-by-page basis, whether
a page is cacheable and/or bufferable.
The CPU caches and write buffers may be enabled for read and write accesses to
on-board SSRAM and DRAM.
The CPU caches may be enabled for read accesses to the ROM and Flash. For
writes, the Flash is essentially an 1/0 device; the CPU D-cache and write buffers
should be disabled for writes to the Flash.
The CPU caches and write buffers must be disabled for accesses to 110 space
(including the IS.AM:EM space).

5.2 Switching the Memory Map
After reset, the ROM is decoded at address 0 and the DRAM is not accessible.
The mechanism for switching the address space is described in Section 3.1.1.

5.3 DRAM
The EBSA-110 supports zero, one or two DRAM SIMMs. If two are :fitted, they
must be of the same type.
After power-on or reset, on-board software must configure the DRAM using this
sequence:
1. Disable refresh requests.
2. Assume the DRAM is BEDO; configure it, set the wrapping mode and 'wake
up' all banks.
3. Enable refresh requests.
4. Determine DRAM type (EDO/BEDO) and configure accordingly.
5. (Optional) Size the memory non-destructively.
6. (Optional) Test the memory.
Each of these steps will now be described in detail.

Configuration of Memory and VLSI Devices 5-1

Configuration of Memory and VLSI Devices
5.3 DRAM
5.3.1 Disable Refresh Requests
After reset, the PIT may be in an unknown state. To disable refresh requests
whilst DRAM configuration is in progress t perform this sequence of PIT writes:
1. Write Ox3a to the PIT_CTLW register (load 16-bit count for channel 0 in mode
5).

2. Write Oxl to the PIT_CTLW register (least-significant count is 1).
3. Write OxO to the PIT_CTLW register (most-significant count is 0).

This will make the counter generate a single refresh request and then no others.

5.3.2 Initialize the DRAM
The initialization sequence is:
1.

Clear the SOFT_BURST bit in the Soft register.

2. Wait until the refresh generated when the refresh counter was disabled
(see previous section) has been completed. If the code is running from ROM
(EPROM or Flash) at this point in the initialization, no additional delay will

be needed.
At this stage, the refresh counter cannot generate any further refresh
requests, and it is safe to set the SOFT_DCBR bit
3.

Set the SOFT_DCBR bit in the Soft register.

4. At each of the following 32 addresses:
for (i=O; i<32; i++)
address := Ox0000.0080 & (i << 22);

perform these accesses:
1. Write the value Ox0000.0000 to the address (actually, the write data is

irrelevant).
This step in the configuration is only required for BEDO DRAMs, and
it sets the wrapping mode to linear burst. Although it is only needed
for BEDO DRAMs it is benign to EDO DRAMs and is a prerequisite to
determining whether EDO or BEDO DRAMs (or no DRAMs at all) are
fitted.
2. Read from the address 9 times. The first read takes the DRAM out of
programming mode. The next 8 reads will 'wake up' the DRAMs.
This step is required for both EDO and BEDO DRAMs.
When coding the write/reads sequence, ensure that all of the accesses are
performed and that they are performed in order (beware of optimizing
compilers).
At this stage in the configuration, the DRAM memory size is not known,
therefore the range of addresses ensures that every bank of DRAM that could
be present gets initialized.
5. Clear the SOFT_DCBR bit.

t It is critical that refresh requests are disabled whilst the SOFT_DCBR bit is set. Failure
to comply with this rule will mean that refresh cycles will spuriously terminate CPU
cycles, leading to unpredictable behavior, which may include system lock-up.

5-2 Configuration of Memory and VLSI Devices

Configuration of Memory and VLSI Devices
5.3 DRAM
5.3.3 Enable Refresh Requests
Set up channel 0 of the PIT to generate periodic refresh requests. The refresh
period is calculated from this data:
•

The slowest supported mclk frequency is 42.3 MHz (23.6ns period).

•

The refresh counter is clocked at mclk/7 = 6.0 MHz (approx.), corresponding
to a clock period of 165ns.

•

The DRAMs require 2048 refresh cycles in 32ms. For a distributed refresh,
this means 1 refresh every 15.625us.

•

The minimum refresh interval must be reduced by an amount corresponding
to the maximum latency to start a refresh. This maximum latency will occur
if a refresh request coincides with a 16-longword load-multiple from DRAM,
which requires a maximum of 54 mclk cycles; 1.28us. This changes the
minimum refresh interval to 14.34us.

Refresh is configured and enabled by performing this sequence of PIT writes:
1. Write Ox36 to the PIT_CTLW register (load 16-bit count for channel 0 in mode
3).

2. Write Ox57 to the PIT_CTLW register (least-significant count is 87 (Ox57)
clock periods of 165ns, which equals 14.34us).
3. Write OxO to the PIT_CTLW register (most-significant count is 0).

5.3.4 Determine the DRAM Type
At this stage the DRAM is in EDO mode (SOFT_BURST is clear). Perform this
sequence:
1. Non-sequential write to address Ox0000.0000 t, data Oxaaaa.aaaa.

2. Non-sequential write to address Ox0000.0004, data Ox5555.55555.
3. Non-sequential read from address Ox0000.0000. If the data is Oxaaaa.aaaa,
the memory is EDO DRAM. If the data is not Oxaaaa.aaaa, the DRAM is
faulty or not :fitted or is BEDO DRAM. Set the SOFT_BURST bit and perform
the read again.
When the SOFT_BURST bit is set correctly, ensure that bursts work correctly by
using non-sequential writes to store data in 4 adjacent locations and then reading
the data back twice; :first by performing a load-multiple (sequential reads) and
then by reading the same locations using non-sequential reads.
This technique works because a BEDO DRAM requires 2 cas_l pulses to access
the :first read data. If it only receives 1 (because the controller is configured for
EDO) it will keep its data bus tristate.

5.3.5 Size the Memory
Many techniques exist. Memory is quantized in units of 4Mbytes, so it is only
necessary to check on 4Mbyte boundaries. A non-destructive probe is preferable.

t This algorithm assumes that, if a single DRAM SIMM is fitted, it is fitted in the correct
socket.

Configuration of Memory and VLSI Devices 5-3

Configuration of Memory and VLSI Devices
5.3DRAM
5.3.6 Test the memory
Use a technique of your choice. To test the memory properly, you should perform
both sequential and non-sequential reads and writes.
At this point, the DRAM is fully configured.

5.4 SSRAM
The synchronous SRAM does not require any configuration.

5.5 EPROM
The EPROM does not require any CQnfiguration.

5.6 Flash
Reading from Flash does not require any configuration. Writing to Flash requires
accesses to other registers within the device. Refer to the manufacturer's data
sheet for details. Refer to Section 3.2.4 for the addressing sequence required to
access sequential bytes during writes to Flash.
The Flash ROM on the EBSA-110 may have a vendor ID of Ox89,0xA2 (Intel
28F008SASA) or Ox89,0xA1 (Intel 28F008SA-L).

5.7 PCM CIA Controller
Before the PCMCIA controller can be configured, the Super I/O IDE device must
be disabled, using the procedure described in Section 5.9.
The VADEM PCMCIA controller has some 'Unique Registers' (registers which
differentiate it from previous-generation chips). These can be enabled by this
code sequence:
•

Perform a byte store of OxOe to address PCMCIA_INDEX

•

Perform a byte store of Ox37 to address PCMCIA_INDEX

The PCMCIA controller can be configured using the sequence shown in Table 5-1.
For each register, the write involves the two-stage process of performing a byte
store of the register number to address PCMCIA_INDEX and then performing a
longword store of the associated data to address (PCMCIA_DATA - 1). The writes
should be performed in the order shown in the table.
Table 5-1

PCMCIA Controller Configuration Sequence

Address

Value

Comment

Ox38
Ox78
Ox39
Ox79
Ox3b
Ox7b
Ox3d

Ox12
Ox12
OxOO
OxOO
OxOO
OxOO
OxOO

A Async clock, card debounce delays
B Async clock, card debounce delays
A Timers off
B Timers off
A GPIO configuration, external chip select disabled
B GPIO configuration, external chip select disabled
A Clear programmable chip select address
(continued on next page)

5-4 Configuration of Memory and VLSI Devices

Configuration of Memory and VLSI Devices
5.7 PCMCIA Controller
Table 5-1 {Cont) PCMCIA Controller Configuration Sequence
Address

Value

Comment

Ox7d

OxOO

B Clear programmable chip select address

Ox3e

OxOO

A Programmable chip select not used

Ox7e

OxOO

B Programmable chip select not used

Ox3f

OxOO

A Disable ATA option

Ox7f

OxOO

A Disable ATA option

Ox02

OxOO

A Power and reset control; oe disabled, resume disabled,
auto-power disabled, Vpp off

Ox02

OxOO

B Power and reset control; oe disabled, resume disabled,
auto-power disabled, Vpp off

Ox16

OxOO

A Card detect and general control register; all off

Ox56

OxOO

B Card detect and general control register; all off

Oxle

OxOO

A,B Global control register; active-high interrupts

Ox03

Ox04

Assign Card A interrupt to IRQ3

Ox43

Ox03

Assign Card B interrupt to IRQ4

Ox05

Ox48

A Interrupt enabled for card and status-change interrupts

Ox45

Ox38

B Interrupt enabled for card and status-change interrupts

Ox06

Ox20

A Enable MEMCS16, disable all memory and 1/0 windows

Ox46

Ox20

A Enable MEMCS16, disable all memory and 1/0 windows

5. 7.1 Setting the PCMCIA Socket Programming Voltage
The programming voltages VPPl, VPP2 are set using the Power and RESETDRV
Control Register. This is at Index Ox02 for socket A and at Index Ox42 for socket
B. The appropriate values for this register are shown in Table 5-2.
Table 5-2 PCMCIA Programming Voltages
Voltage

d[3:0]

OxO

Ox8

12V

Ox2

Off

Oxa

5.7.2 Setting a PCMCIA Socket Memory Window
The PCMCIA controller provides facilites for mapping portions of the 64Mbyte
(26-bit) PCMCIA address space into the 16Mbyte (24-bit) ISA address space. On
the EBSA-110 the ISA address space is decoded in the ISAMEM and ISAIO areas
of the address space.
The controller allows a number of windows to be defined. Each window maps
a region of PCMCIA address space into a region of ISA address space. Each
window is configured using a set of control registers. For each socket (socket A,
socket B) there are 2 I/O windows and 5 memory windows. Memory windows are
also used to access attribute space on the cards.

Configuration of Memory and VLSI Devices 5-5

Configuration of Memory and VLSI Devices
5. 7 PCM CIA Controller
Setting up a memory or I/O window requires these steps:
•

Choose the system address space range.
The system address is the address in the 24-bit ISA address space. The lower
64kbytes of this space cannot be allocated to memory windows.

•

Calculate the equivalent range in the EBSA-110 address space.
The ISA address space is a subset of the EBSA-110 address space, and is
sparsely mapped into EBSA-110 address space.

•

Calculate the window register values.

•

Select which window to use.

•

Configure the window registers.

•

Enable the window.

Here is a worked example of setting up a memory window. The process for setting
up an I/O window is similar. Refer to the manufacturer's data sheet for more
information.
Goal: set a window from system space into attribute space on Socket A using
memory window 1, so that attribute space from address OxO to Oxffff is
available.

* Choose the system address space range: The addresses from OxO to Oxffff are
not available, so choose addresses Oxl.0000 - Oxl.ffff.
* Calculate the address in EBSA-110 address space: The PCMCIA system address space
starts at PCMCIAMEM_BASE (0xe800.0000). The PCMCIA system address space is
sparsely mapped because it only occupies 16 bits of the 32-bit address
bus; its data path is accessible on the two low-order byte lanes. Therefore,
the equivalent EBSA-110 address range is:
(2 * system address space range) + PCMCIAMEM_BASE
= range Oxe802.0000 -> Oxe803.ffff
* Calculate the window register values:
start_address = Oxl.0000
stop_address = Oxl.ffff
offset = pcmcia_address - start_address = 0 - Oxl.0000 = Oxffff .fOOO
The pcmcia_address is the start address in PCMCIA address space that the
window is mapped to.
System Memory Address Mapping Start Reg. Low = (start_address >> 12) AND Oxff
System Memory Address Mapping Start Reg. High= ((start_address >> 20) AND OxOf) OR Ox80
- the OR of Ox80 selects a 16-bit data path.
System Memory Address Mapping Stop Reg. Low = (stop_address >> 12) AND Oxff
System Memory Address Mapping Stop Reg. High = (stop_address >> 20) AND OxOf
Card Memory Offset Address Reg. Low
= (offset >> 12) AND Oxff
Card Memory Offset Address Reg. High
= ((offset>> 12) AND Oxffl OR Ox40
- the OR of Ox40 selects attribute space.
* Select card A window 0. Its registers are at:
System Me.~ory Address Mapping Start Reg. Low = OxlO
System Me.~ory Address Mapping Start Reg. High = Oxll
System Memory Address Mapping Stop Reg. Low = Oxl2
System Memory Address Mapping Stop Reg. High = Oxl3
Card Memory Offset Address Reg. Low
= Oxl4
Card Memory Offset Address Reg. High
= Oxl5

* Configure the window registers:

5-6 Configuration of Memory and VLSI Devices

Configuration of Memory and VLSI Devices
5. 7 PCM CIA Controller
write OxlO to register at OxlO
write Ox80 to register at Oxll
write Oxlf to register at Ox12
write OxOO to register at Ox13
write OxfO to register at Ox14
write Ox7f to register at Ox15
Each write is a 2-stage process that involves writing the register number to the
PCMCIA_ADDRESS register then writing the data to the PCMCIA_DATA register.

* Enable the window by reading the value of the register at address Ox06,
OR with OxOl (to enable memory window 0) and write the value back.

5.8 Ethernet Controller
The Am79C961A is configured without an EEPROM. In this mode, it will enter
Software Relocatable Mode after powerup or reset. On-board software must
configure the device using this sequence:
l.

Send the initiation key.

2. Put the device into 'CONFIG' state.
3. Configure the Plug-and-play registers.
4. Disable the Plug-and-play registers.

5.8.1 Send the Initiation Key
The initiation key is a specific byte sequence which must be written to the PNP_
ADDRESS registert. This process takes the Am.79C961A out of its 'Wait For
Key' state. The pattern must be sequential; any other I/O cycles to the Ethernet
controller will reset the state machine that is checking the pattern. After a reset,
the Plug-and-play registers are configured for 8-bit I/O cycles, therefore these
writes must be performed as longword stores to address (PNP_ADDRESS-1)
(Refer to Section 3.9.1). The key:j: is:
6b, 35, 9a, cd, e6, f3, 79, be,
Se, af, 57, 2b, 15, Ba, c5, e2,
fl, f8, 7c, 3e, 9f' 4f, 27, 13,
09, 84, 42, al, dO, 68, 34, la

5.8.2 Put the Device into 'CONFIG' State
When the key has been written, the Ethernet controller Plug-and-play state
machine can be transitioned to the 'CONFIG' state. This is achieved using the
sequence shown in Table 5-3. For each register, the write involves the two-stage
process of performing a longword store of the register number to address (PNP_
ADDRESS-1) and then performing a longword store of the associated data to
address (PNP_WRDATA-1). The writes should be performed in the order shown
in the table.

t The addresses of all of these registers are described in Section 3.5.

+ This is not the same as the key that is used when the Am79C961A is configured with an
EEPROM.

Configuration of Memory and VLSI Devices 5-7

Configuration of Memory and VLSI Devices
5.8 Ethernet Controller
Table 5-3 Ethernet Plug-and-play Register Configuration Sequence
Address

Name

Value

Comment

Ox02

Configuration control

Ox05

Reset CSN to 0

Ox03

Wake[CSNJ

OxOO

Go to ISOLATION state

OxOO

Set RD_DATA port

Ox80

Set RD_DATA port

Ox06

Card Select Number

OxOl

Set CSN to 1 and go to CONFIG
state

5.8.3 Configure the Plug-and-play Registers
The next stage in the initialization process is to write configuration values to the
Plug-and-play registers. Each write requires the same 2-stage process described
in the previous section. The recommended values are shown in Table 5-4; they
should be written in the order shown.
Table 5-4 Ethernet Plug-and-play Register Initial Values
Address

Name

Value

Comment

Ox43

Boot PROM base

Oxfe

Disable boot PROM decode

Ox48

SRAM base23:16

OxOc

Set SRAM base

Ox49

SRAM base15:08

OxOO

Ox4a

SRAMMemcon

Ox02

Set SRAM access width to 16-bit

Ox4b

SRAM limit23:16

Ox:ff

Set SRAM size to 64K

Ox4c

SRAM limit15:08

OxOO

Ox60

IO base15:8

Ox02

Ox61

IO base07:00

Ox20

Ox70

IRQ sel

Ox03

Select interrupts on IRQ3

Ox71

IRQ type

Ox02

Select active-high edge-sensitive

Set base address in I/O space to
Ox220

Ox74

DMA sel

OxOO

No DMA channel

oxro

Vendor-defined

Ox04

8-bit I/O, enable address PROM

Ox31

1/0 Range Check

OxOO

Disable I/O range check

Ox30

Activate

Activate the logical device

oxro

Vendor-defined

Ox05

Switch to 16-bit I/O

At the end of this sequence, the Ethernet controller has been configured to use
16-bit I/O and so all subsequent accesses to the device can use byte and half-word
loads and stores.

5.8.4 Disable the Plug-and-play Registers
The final stage in the initialization process is to disable the Plug-and-play
registers. This step must be performed before accesses to the UID ROM or buffer
memory are possible. Use this code sequence:
•

Write Ox02 to the PNP_ADDRESS register to select the configuration control
register.

•

Write Ox02 to the PNP_WRDATA register to make the Plug-and-play state
machine transition back to the WAIT_FOR_KEY state.

5-8 Configuration of Memory and VLSI Devices

Configuration of Memory and VLSI Devices
5.8 Ethernet Controller
Since the Ethernet controller has now been configured to use 16-bit I/O, these
accesses should be performed using half-word stores.
At this point, the Ethernet controller is configured and its registers can be
accessed using the NET_IDP, NET_RAP and NET_RDP registers. The IEEE
unique identification address can be read from the sequence of addresses starting
at the NET_UID address.

5.9 Super 1/0 Controller
No configuration is required before accessing the COMl, COM2 or LPTl ports.
The Superl/O UARTs and LPT registers should be left at their default addresses,
so that the interrupt assignment is not changed (LPT2 interrupt on IRQ7, COMl
interrupt on IRQ4 and COM2 interrupt on IRQ3).
The addresses of the (unused) IDE logic within the Super I/O controller clash
with the addresses used by the PCMCIA controller. Therefore, it is necessary to
disable the IDE logic. Use this code sequence:
1. Write OxOO to the SIO_INDEX register to select the Function Enable register

(all of these accesses should be byte loads and stores).
2. Read the SIO_DATA register.
3. AND the value read with OxBF to clear bit 6; this disables the IDE function.
4. Write the new value back to the SIO_DATA register.
5. Write the same value back to the SIO_DATA register a second time. The SIO
requires this double write before it will update its registers. If you code this
sequence using a high-level language, make sure that your compiler does not
optimize out this second write.

5.1 O Programmable Interval Timer
Since the interrupt controller expects level-sensitive interrupts, the PIT timer
channels 1 and 2 must be operated in ModeO.
Channel 0 is used as the refresh timer and its initialization is described in
Section 5.3.

Configuration of Memory and VLSI Devices 5-9

6
Performance
This section discusses the performance of the memory and I/O sub-systems.
Performance is discussed in terms of the number of stall cycles that are inserted
into a bus transaction during accesses to the various devices on the EBSA-110.
The waveforms described in Chapter 11 show most of the scenarios described
here.

6.1

Synch~onous SRAM Accesses
During CPU write cycles to synchronous SRAM, no stall cycles are inserted. This
is true for both non-sequential and sequential cycles.
During CPU read cycles from synchronous SRAM, one stall cycle is introduced
at the start of each (sequential or non-sequential) bus cycle. This stall cycle is
required to fill the read pipeline of the SSRAM. During read sequential cycles, an
additional two stall cycles are inserted whenever a new address must be loaded
into the SSRAM. A reload occurs either after 4 beats of data have been read
(for aligned accesses or wrapped cache line fills) or when the address of the read
crosses an INT16 boundary (of all other reads). The first stall cycle is required to
load the new address into the SSRAM and the second wait state is required to fill
the read pipeline of the SSRAM.
Cache line fills always wrap around INT16 boundaries, making the SSRAM reads
very efficient. Cache line fills will experience a total of 3 inserted stall cycles.
A worst-case sequential read of 8 INT4s would cross an INT16 boundary three
times during the read, and would therefore experience a total of 5 inserted stall
cycles.

6.2 EDO DRAM Accesses
Accesses to EDO DRAM require stall cycles to be inserted to meet the access time
of the DRAMs.
Sequential accesses to EDO DRAM are always performed in page mode, so that
the overall access time is lower than the equivalent non-sequential accesses.
The performance of EDO DRAM accesses is shown in Table 6-1.

Performance 6-1

Performance
6.2 EDO DRAM Accesses
Table 6-1 Stalls Added During EDO DRAM Accesses
Cycle Type

Total Stalls Inserted

Non-sequential read

2-beat sequential read

3-beat sequential read

4-beat sequential read

8-beat sequential read

Non-sequential write

2-beat sequential write

3-beat sequential write

4-beat sequential write

8-beat sequential write

6.3 BEDO DRAM Accesses
Accesses to BEDO DRAM require stall cycles to be inserted to meet the access
time of the DRAMs. Read accesses incur an overhead because (relative to a
normal DRAM access) an extra CAS pulse is required to start the fill of the
data pipeline. Write accesses incur an overhead because (relative to a normal
DRAM access) an extra recovery cycle is required at the end of the cycle, prior
to negating RAS. This recovery cycle only incurs a performance penalty when
back-to-back DRAM cycles are performed (refer to Section 6. 7).
Accesses to BEDO are most efficient when aligned blocks of data are being read
and written. This makes it well suited to the bus traffic generated in systems
with caches.
When unaligned blocks of data are being read and written a performance penalty
is incurred by the extra cycles needed to abort a burst and reload the column
address.
The performance of BEDO DRAM accesses is shown in Table 6-2.
Table 6-2 Stalls Added During BEDO DRAM Accesses
Cycle Type

Total Stalls Inserted

Non-sequential read

Aligned 2-beat sequential read

Aligned 3-beat sequential read

Aligned 4-beat sequential read

Aligned 8-beat sequential read

Unaligned 2-beat sequential read

Unaligned 3-beat sequential read

Unaligned 4-beat sequential read

Unaligned 8-beat sequential read

22
(continued on next page)

6-2

Performance

Performance
6.3 BEDO DRAM Accesses
Table 6-2 (Cont.) Stalls Added During BEDO DRAM Accesses
Cycle Type

Total Stalls Inserted

Non-sequential write

Aligned 2-beat sequential write

Aligned 3-beat sequential write

Aligned 4-beat sequential write

Aligned 8-beat sequential write

Unaligned 2-beat sequential write

Unaligned 3-beat sequential write.

Unaligned 4-beat sequential write

Unaligned 8-beat sequential write

Aligned 4-beat sequential full write
Aligned 8-beat sequential full write

.Aligned accesses never incur the performance penalty of aborting the DRAM
burst. The unaligned accesses are designed to cross as many block boundaries as
possible (once for 2-beat, 3-beat and 4-beat, twice for 8-beat).
BEDO writes only run at the same speed as EDO writes. The reason for this is
that the cycle must be stalled to allow the byte masks to become valid for each
beat in turn. In some circumstances, the SA-110 is able to determine that all
byte masks will be asserted for all beats of a sequential cycle. Such a cycle is
called a 'full write' and corresponds to a merged write buffer write or the eviction
(cast-out) of a dirty cache block. In these circumstances, it is not necessary to
decode address information and this allows the cycle time of full writes to be
reduced.

6.4 Performance Impact of DRAM Refresh
The bandwidth required by refresh is calculated as follows: DRAMs require 2048
refresh cycles in 32ms. The refresh sequence (shown in Figure 11-13) takes 9
clocks at 18ns. Therefore, in a 32ms period, the percentage of time occupied by
DRAM refresh is (2048*9*18ns/32ms)*100 =1.03%.
In practice, the impact of DRAM refresh will be lower than that :figure. CPU
cache accesses, I/O accesses and SSRAM accesses can all take place in parallel
with refresh cycles. The only time that a refresh cycle will use system bandwidth
is if the CPU attempts to access DRAM whilst a refresh cycle is in progress.

6.5 EPROM and Flash Accesses
Accesses to the EPROM and the Flash run at the same speed, even though the
Flash device actually has a shorter access time. Reads from these devices have
stall cycles inserted so that a sequence of bytes can be packed into a 32-bit data
unit, and so that the access time of the devices is satisfied. Writes to the Flash
have stall cycles inserted so that the access time is satisfied.
The performance of ROM (EPROM and Flash) accesses is shown in Table 6-3.

Performance 6-3

Performance
6.5 EPROM and Flash Accesses
Table 6-3 Stalls Added During EPROM and Flash Accesses
Cycle Type

Total Stalls Inserted

Non-sequential read

2-beat sequential read

3-beat sequential read

130

8-beat sequential read

345

Non-sequential write

6.6 1/0 Accesses
Accesses to I/O devices have stall cycles inserted in order to meet address setup,
cycle time and address hold requirements for the slowest device. The PCMCIA
controller allows plug-in cards to reduce the cycle time on an access-by-access
basis, using zws_l. The PCMCIA controller and the Ethernet controller allow the
cycle time to be extended on an access-by-access basis, using rdy. rdy allows the
cycle time to be extended infinitely. zws_I allows the cycle time to be reduced,
but there is a predetermined minimum cycle time.
The performance of I/O accesses is shown in Table 6-4.
Table 6-4 Stalls Added During 1/0 Accesses
Cycle Type

Total Stalls Inserted

Normal read

20
20
13
13

Normal write
Fastest read (using ZWS_L)
Fastest write (using ZWS_L)

6.6.1 Ethernet Buffer Memory Bandwidth
The Ethernet memory bandwidth cannot be simulated accurately and so was
measured experimentally.
With the Ethernet controller idle, the bandwidth into Ethernet buffer memory
was measured with the I-cache on, and the write buffer and D-cache off. A tight
CPU write loop sustained a bandwidth of 3.3E6 bytes/second. A tight CPU read
loop sustained a bandwidth of 3. 7E6 bytes/second.
With the Ethernet controller transmitting and receiving continuously (in internal
loopback) the bandwidth into the Ethernet buffer memory was reduced by 25%.

6. 7 Overlap of Cycles
At the end of a DRAM cycle, there is a period of time called the RAS precharge
period. A new DRAM access cannot start during this time. The state machines
on the EBSA-110 are designed in such a way that an SSRAM access is not
stalled due to the RAS precharge period of a previous DRAM cycle. This saves
clock cycles in some situations. However, if a new DRAM access starts before
the precharge for a previous cycle has completed, stall cycles must be inserted.
Table 6-5 shows how many additional stall cycles are inserted when the second
cycle type follows the first cycle type as a back-to-back cycle (that is, 1 idle cycle
between the two bus transactions).

6-4 Performance

Performance
6. 7 Overlap of Cycles
Table 6-5 Stalls Caused by Back-to-Back Cycles
First Cycle

Second Cycle

Additional Stalls

SSRAM access

Any access

IJO access

SSRAM access

J/O access
J/O access

IIO access
Any DRAM access

0
0

EDO read/write

SSRAM access

EDO read/write

IIO access

EDO read/write

Any DRAM access

BEDOread

SSRAM access

BEDOread

IIO access

BEDOread

Any DRAM access

BEDO write

SSRAM access

BEDO write

IIO access

BEDO write

Any DRAM access

0
2

Performance 6-5

7
Software Development Environment
This chapter describes the types of images that may be built for the EBSA-110,
and how to use ARM's software development toolkit to build these images. The
toolkit itself is described in the ARM Software Development Toolkit Reference
Manual.
Two types of image are described:
•

Loadable debuggable images

•

Standalone Flash images

Flash images may be programmed into Flash using the FMU utility described in
Section 9.1.
Note - - - - - - - - - - - -

This chapter assumes that the board is using the Demon debug server.
Future versions of the EBSA-110 are expected to replace this with the
Angel debug server. When this happens an addendum or technical note
will be issued describing the differences.

7.1 Loadable Debuggable Images
These images are run under the control of the Demon debug agent held in ROM
communicating with either arm.sd or the ARM Windowing debugger.

7.1.1 Building
These images may be written in C or assembler. No special options are
needed when assembling or compiling. Debuggable C programs (and optionally
debuggable assembler programs) should be linked with the Demon (semi-hosted)
C library. To allow debugging they should be linked using either the -AIF or the
-AIF -BIN options, although images linked with the -BIN option can be debugged
at the machine code level.
Images that are to be loaded across the serial line using the debugger's load
command may be linked to use any base address in SSRAM or DRAM except
addresses below Ox8000.
Images that are to be loaded using bootp must also avoid loading into the memory
containing the bootp program and its buffers. Two versions of the bootp utility
are provided; one loads at Ox8000 and the other loads at Ox40000000, so this
should not normally be a problem.
Images that use the C library to create their user stack should be linked to
addresses in the :first alias (i.e. the one starting at OxO or Ox40000000) of the area
of RAM they are using.

Software Development Environment 7-1

Software Development Environment
7.1 Loadable Debuggable Images
7 .1.2 Run Time Environment
7 .1.2.1 Memory Map

All RAM except address 0 to OxSOOO is available to the program. DRAM will have
been initialized before entry to the program. The MMU, write buffer, and caches
will not have been initialized unless you have done this by running a previous
program or by writing to the system coprocessor using debugger commands.
The C heap will be placed directly above the text segment of the program. If the
program is running from DRAM the C library initialization functions will place
the user stack at the top of DRAM. If it is running from SSRAM the user stack
will be placed at the top of SSRAM.
7.1.2.2 C Library Support

The C library is described in the toolkit manual. All standard C functions are
supported. All reference to files (including references to standard input and
output) refers to these files on the host. This means that, for example, a call to
printf( ) prints a string to the host that is running the debugger.
7.1.2.3 Exception Vectors

The Demon debug monitor uses the Undef, SWI and FIQ exception vector entries.
The program can safely modify any other exception vector to jump to its own
exception handlers. The program can also install its own handlers using SWI_
InstallHandler. This is described in the Demon documentation.
7 .1.2.4 Access to VO Devices

Demon uses the COMl serial port. The program must not access this device. All
other devices may be used by the program.

7.2 Standalone Flash Images
These images boot directly from Flash.

7.2.1 Building
These images may be written in C or assembler. No special options are needed
when assembling or compiling. You must provide startup code and the code of
any library functions used (refer to Section 7.2.2.2). There are two ways of linking
such images:
•

-AIF -BIN -BASE n
If the base address is outside of the address range of the Flash, the PBL
will copy the image to its base address in system RAM (removing the
header in the process) and execute it from its entry point; the image will
execute from RAM.

In this case, the image may occupy non-contiguous blocks in Flash.
If the base address is equal to the Flash block address+ OxcO, the PBL
will execute the image by branching to its entry point; the image will
execute from Flash.

In this case, the image must occupy contiguous blocks in Flash.
If the address does not meet either of these requirements, the FMU will
report an error and will not program the image into Flash.

Images linked with this option may use any base address in RAM.

7-2 Software Development Environment

Software Development Environment
7.2 Standalone Flash Images
•

-AIF-BASE n-The image will execute from Flash. Requirements are:
The image must occupy contiguous blocks in Flash.
The image must not contain any writable initialized data.
The address of the first Flash block to be used for the image must be
known at link time.
The base 'n' must be the address of the Flash block + Ox40.
In this case, the image is started by branching to the BL instruction that is
the first longword of the AIF header. The FMU does not validate the entry
point.
This option should normally be avoided (except for programs that relocate
themselves to RAM during initialization) since accesses to Flash are much
slower than access to RAM.

7.2.2 Run Time Environment
7.2.2.1 Memory Map

All of RAM is available to the program. If the program is run from RAM, then
DRAM will have been initialized before entry to the program. If it is run directly
from Flash, then nothing will have been initialized. The boot time memory map
will still be in use although the PC will be in the first alias above Ox80000000
of the Flash block (not in a low alias). The MMU and caches will not have
been initialized. If the program is running from DRAM or Flash, the C library
initialization functions will place the user stack at the top of DRAM. If it running
from SRAM, the user stack will be placed at the top of SRAM.
7.2.2.2 C Library Support

ARM's software development toolkit includes sources and porting information for
two run-time libraries; a minimum standalone library and an ANSI C library.
EBSA-110 ports of these libraries may be supplied as part of the firmware
database in the hardware developer's kit t.
7.2.2.3 Exception Vectors

The program may modify and use the exception vectors without restriction.
7.2.2.4 Access to 1/0 Devices

If a C library is used, it will provide routines to access some devices (for example,
the COMl serial port) and it will expect exclusive access to the associated
underlying hardware. Other than this, the program may access any device.

t Early versions of the HDK are unlikely to provide this.
Software Development Environment 7-3

8
On-Board Software
When the EBSA-110 is reset or powered up, code execution commences with a
fetch from the reset vector at location 0. Depending upon a jumper setting on the
board, the reset vector can be supplied from the EPROM or from a Flash ROM.
Usually, the system will boot from an image called the Primary Boot Loader
(PBL), which is stored in the Flash ROM.
A newly-manufactured system, or a system in which the Flash has become
corrupted, cannot boot from Flash. In this case, a special EPROM, called the
Startup EPROM, is used. The Startup EPROM performs power-on diagnostics
and programs the PBL into the Flash.
This chapter describes the PBL, the Startup EPROM and the EBSA-110
diagnostics.

8.1 The Primary Boot Loader
The Primary Boot Loader (PBL) is a special image that is programmed into the
:first block (block 0) of the Flash. Normally, the PBL is the first code executed
when the EBSA-110 comes out of reset.
The Flash can contain a number of different images; the main function of the PBL
is to determine which image to execute and to execute the image. If necessary,
the PBL will load the image from Flash into system memory.
Images are programmed into Flash using the Flash Management Utility (FMU)
described in Section 9.1.
The format of the images in Flash is described in Section 8.2.
When the PBL is executed, it performs these tasks:
•

Read the value of the boot jumpers to determine which image to boot. The
boot jumpers are on J4, and 8 images can be selected using the settings
shown in Table 8-1.

Table 8-1 Boot Image Selection
J2:13-14

J2:11-12

J2:13-14

Action

Enter ARM remote debug stub within PEL
image
fit
fit

fit

Boot image 1 - normally the diagnostics

fit

Boot image 2
Boot image 3
(continued on next page)

On-Board Software 8-1

On-Board Software
8.1 The Primary Boot Loader
Table 8-1 (Cont.) Boot Image Selection
J2:13·14

fit
fit
fit
fit

J2:11·12

J2:13-14

fit
fit
fit

fit

Action

Bootimage 4
Boot image 5
Boot image 6
Bootimage 7

•

If Image 0 is selected then enter the ARM remote debug stub within the PBL
image.

•

If any other image is selected:
Search for the image in Flash, and verify that the checksum is correct.
If image is not found or is corrupt (bad checksum), behave as though the
selected image is image 0.
If the image is in executable AIF format, jump to the image (the
system memory map has not been changed and the DRAM has not been
initialized).
If the image is in non-executable AIF format, then:

Switch the memory map

Initialize DRAM

* Load the image into memory at the addresses defined in the AIF
header

* Jump to the image's entry point

8.2 The Format of Images in Flash
The Flash ROM is a lMbyte part, organized as sixteen 64Kbyte blocks. Block 0
(at address Ox0000.0000, after reset) is reserved for the PBL. The remaining 15
blocks can be used to hold other images.
Each image, apart from the PBL, has an image header that allows it to be stored
across non-contiguous blocks. Only the first block used by the image has an
image header. Any individual block is only used by none or one image. Any block
that is not in use will be in its erased state.
The format of an image stored in the Flash is basically AIF (ARM Image Format),
with a few additional bytes prepended. The format is shown in Table 8-2.
When the FMU is used to program an image into Flash, the FMU will create and
prepend the header information onto the image.
------------------------- Note -----------------------You may write an alternative Flash programming utility, but it should
follow the defined Flash structure so that the PBL can load the image.

8-2 On-Board Software

On-Board Software
8.2 The Format of Images in Flash
Table 8-2 Flash Image Header
Offset
(bytes)

Size
(bytes)

Name

Description

Type

BL to AIF header (for executable AIF) or BL to
image entry point (for non-executable AIF on
image to be executed from Flash) or NOP (for
non-executable AIF executed from RAM)

Number

Unique image number (0 to Oxfl)

Sig

Ox55 Oxaa OxOO

Map

Allocation map. Bit 0 represents block 0, bit 31
represents block 31 (only bits 15:0 are required
for the current Flash part)

Checksum

Checksum of im.age including headers, using
the algorithm described below

Length

Image length (including all headers) - used to
determine what gets checksummed

Name

ASCII string identifying name of image.
Unused characters should be set to Ox20
(ASCII space)

Bootflags

Bit 0 is NoBoot. When set for an image, the
PBL will load the image but then pass control
to the ARM remote debug stub within the PBL.

Reserved

Reserved for future use

128

AIF header

AIF header for image

The headers use a total of 192 bytes. The :first free byte is at offset 192 (OxcO).
The checksum is formed by taking the 2's complement of the 32-bit sum (ignoring
carry) of all longwords of the header and image, excluding the checksum itself, as
specified by the length field. If the length is not an integral number of longwords,
the 'missing' bytes are set to Oxff (the unprogrammed state of bytes in Flash).
When the checksum is correct, a 32-bit sum (ignoring carry) of all longwords of
the header and image, including any bytes required to round the length up to an
integral number of longwords, will be 0.
Block 0 of the Flash will always contain image 0, the PBL image. It is undefined
whether this image contains an image header.
Images can have an image number between 0 and Oxff, but the PBL can only load
and start image numbers 0-7.
Software that deletes an image in Flash should erase all the blocks used by
that image. Software that programs an image in Flash should determine which
blocks are free by checking each block for an image header and then ORing the
allocation maps of all the valid image headers.

8.3 The Startup EPROM
The Startup EPROM performs manufacturing diagnostics on the board. This
process includes programming the PBL image into the Flash. After initial
programming of the Flash (which is done during manufacture), you should not
normally boot the board from the startup EPROM unless Flash image 0 (the
PBL) is missing or has been corrupted. Section 8.4.2 describes the diagnostic
tests.

On-Board Software 8-3

On-Board Software
8.3 The Startup EPROM
To execute the Startup EPROM:
•

Check that the correct EPROM is fitted.

•

Fit jumper J4 pin 6-8 (this selects booting from the EPROM).

•

Reset or power-cycle the board.

During the tests, the red 'debug' LED and the COMl port provide progress
information. Refer to Section 8.4.2.
Once the tests have been completed successfully, remove the jumper from J4 pin
6-8 and reset the board.

8.4 Diagnostics
There are 2 versions of the diagnostic tests:
•

Power-on diagnostics

•

Manufacturing diagnostics

The manufacturing diagnostics are a superset of the power-on diagnostics. The
manufacturing diagnostics are run when the 'startup EPROM' is used (see
Section 8.3). The power-on diagnostics are normally programmed into the Flash
ROM as Image 1 and executed when Image 1 is selected.

8.4.1 Getting Ready to Run the Diagnostics
To run the diagnostics:
1. Use null-MoDem cables to connect terminals (or virtual terminals running on
a PC or workstation), to the board's COMl and COM2 ports. Configure both
terminals for 9600 baud, 8-bit data, 1 stop bit, no parity, no flow control.
2. (Optionally) Connect an Ethernet loopback connector to the Ethernet port.
3. (Optionally) Connect the parallel port loopback connector to the parallel port.
A suitable loopback connector is described in Section A9.3.
4. Set the jumpers to select either the manufacturing diagnostics or the poweron diagnostics in accordance with Table 8-3.
Table 8-3 Selecting Diagnostics
To select..

J2:2-4

J2:13-14

J2:11-12

J2:9-10

Power-on diagnostics

remove

fit

Manufacturing diagnostics

fit

don't-care

5. Reset or power-cycle the system.

8.4.2 Description of Tests
This section describes the diagnostic tests, in order of execution, and highlights
differences between the power-on diagnostics and the manufacturing diagnostics.
It also includes a sample output from running the tests.
The tests performed are:
1. LED test: flash debug LED 8 times. This demonstrates that the tests have
started, and that some 110 path is working.

8-4 On-Board Software

On-Board Software
8.4 Diagnostics
2. Memory map decode test: jump to high-order image of ROM, :flip memory
map and check that low-order image disappears.
3. Write banner messages to COMl and COM2. If these banner messages are
not seen within 15 seconds of the tests starting, then one of the following
problems has occurred:
i

The ROM cannot be accessed at its high address location.

ii The UART cannot be accessed or is not functioning.

iii The terminals (or virtual terminals) attached to the ports are wrongly
configured.
From here on, a progress message is written to COMl each time a test is
started or completed, and any errors detected by the program are reported to
COMl.
4. Soft I/O test: verify all read/write bits function correctly.
5. Size and test SSRAM. The SSRAM tests performed are:
i

Write the address of each 32-bit location to itself (using word writes), then
read them all back (using word reads) and check that they contain the
correct values.

ii Write the address of each 32-bit location shifted right by 16 to itself,
then read them all back and check that they contain the correct values.
This tests that the upper bits of each word are being written and read
correctly.
iii Write a value to each byte of SSRAM (using byte writes), then read them
all back using byte reads checking the values read.

iv Read back the values written by the previous test using word reads.
v Store multiples of 1 to 5 words are done at each possible alignment in a
4-word block. After each store multiple, the program tests that the correct
values have been stored, that no other memory (close to the 4-word block)
has been corrupted, and that the registers have not been corrupted.
vi Load multiples of 1 to 5 words are done at each possible alignment in a 4
word block. After each load multiple, the program tests that the correct
values have been read and that memory close to the 4-word block has not
been corrupted.
6. Copy remaining tests to SSRAM, and jump to SSRAM.
7. Test PIT counter 0 (refresh timer).
8. Configure DRAM and identify the type of DRAM fitted.
9. Size and test DRAM. The SSRAM tests are repeated on the DRAM. Test 3
(writing and reading every byte of DRAM) may take up to 1 minute.
10. Identify CTB type (OS or ARCH).
------------------------ Note ------------------------

Any errors detected before this point are regarded as fatal; the tests are
aborted. Any errors detected after this point are regarded as recoverable,
and the tests attempt to continue.

On-Board Software 8-5

On-Board Software
8.4 Diagnostics
11. Test PIT counters 1 and 2, including the interrupt paths associated with these
PIT counters. This also tests the FIQ and IRQ control registers (or at least
the bits associated with these interrupts) in the trick box logic.
12. Test the Ethernet controller.
13. Test the Ethernet UID ROM.
14. Test the Ethernet buffer RAM.
15. Test Ethernet input (using internal loopback), and the Ethernet interrupt
paths.
16. Test Ethernet input using external loopback. This test will generate a
warning if an external loopback is not detected.
17. Test the parallel port control registers.
18. Test the parallel port using external loopback. This test will generate a
warning if an external loopback is not detected.
19. Test PCMCIA controller, and the associated interrupt paths. If a card is
fitted, print the card's attribute space.
20. Test trick box aborts.
21. (Architectural logic only) Test the trick box cycle counters.
22. Test Flash control registers. (This does not reprogram any location in the
Flash. It identifies the vendor and checks that the programming voltage is
correct.)
23. Calculate the processor and bus speeds of the board.
24. Test input from COMl and COM2 and the COMl and COM2 interrupt paths.
This test requires user input on the terminals attached to COMl and COM2;
follow the instructions printed to COMl and COM2.
25. Read from Flash and report if any valid images are found.
26. You will be asked whether an integrity check should be performed on the
Flash. If you agree (by answering 'y'), then this test performs an integrity
test of blocks 1-15 of the Flash. Any blocks that contain valid images will be
left unchanged. Any other blocks will be erased.
27. Read the jumper values from the soft register.
28. Print a summary of the detected configuration of the board. The information
printed includes:
i The processor's clock speeds.
ii The type of logic fitted to the board.
iii The amount of SSRAM fitted.
iv The amount and type of DRAM fitted.
v The jumper values read from the soft register.
vi The MAC address read from the Ethernet UID ROM.

29. You will be asked if this summary is correct.
30. Print a "Tests passed" or "Tests failed" message. If the tests failed, print a
summary of the failures.

8-6 On-Board Software

On-Board Software
8.4 Diagnostics
31. (Manufacturing diagnostics only) If some of the tests failed, or there is a valid
image in Flash block 0, ask whether Flash block 0 should be reprogrammed.
If you respond by typing 'n', then the tests are terminated at this point.
32. (Manufacturing diagnostics only) Program the PBL into block 0 of the Flash.
33. (Manufacturing diagnostics only) Program the power-on diagnostics into
Flash as image 1.
The processor is explictly not tested by the self-tests, although the processor may
be assumed to be working more or less correctly if the tests run at all.
If the EBSA-110 fails its power-on diagnostic tests, refer to Appendix B.

An example of the output produced (on COMl) by the diagnostics is shown below.
The output on your system may vary slightly from this, due to later additions to
the diagnostics or a different board configuration.

Starting EESAllO selftests VO.O; this is COMl. Results will be reported here
*** Testing Soft register R/W bits ***
Testing all bits
Test Passed
*** Soft register R/W bit tests complete ***
128Kbytes of SSRAM detected
*** Starting SSRAM tests ***
Testing word writing each word's address to itself
Test Passed
Testing word writing each word's address to its top halfword
Test Passed
Testing byte writing each byte; contents of each byte should be
address mod 255
Test Passed
Testing reading the data written by the previous test as words
Test Passed
Store multiple tests starting
Test Passed
Load multiple tests starting
Test Passed
*** SSRAM tests complete ***
*** Copying remaining tests to SSRAM ***
*** Now executing tests from SSRAM ***
*** Testing Refresh Timer ***
Testing counter 0 without interrupts
Test Passed
*** Refresh Timer Tests Complete ***
*** Starting DRAM tests ***
Initializing DRAM
Either no DRA.~ is fitted or EDO DRAMs are fitted
Sizing DRAM
DRA.~ size is
OxlOOOOOO
Testing word writing each word's address to itself
Test Passed
Testing word writing each word's address to its top halfword
Test Passed
Testing byte writing each byte; contents of each byte should be
address mod 255
Test Passed
Testing reading the data written by the previous test as words
Test Passed
Store multiple tests starting
Test Passed
Load multiple tests starting
Test Passed
*** DRA.~ tests complete ***
Getting CBT type
On-Board Software 8-7

On-Board Software
8.4 Diagnostics
CTB configured as ARCH
*** Testing PIT counters 1 and 2 ***
Testing counter 1 without interrupts
Test Passed
Testing cou.~ter 2 without interrupts
Test Passed
Testing IRQ path for counter 1
Test Passed
Testing IRQ path for counter 2
Test Passed
Testing FIQ path for counter 1
Test Passed
Testing FIQ path for counter 2
Test Passed
*** Tests for PIT counters 1 and 2 complete ***
*** Testing ethernet controller and associated devices ***
Plug and play register access:
Test Passed
MAC address (08-00-2b-95-ld-7b)
Test Passed
Checking Checksum
Test Passed
Testing CSRO access
Test Passed
Testing CSRl writes
Test Passed
Testing shared RAM
Testing haif word writes ot each word's in shared RAM address to itself
Test Passed
Testing byte writes and reading each byte of shared RAM
Test Passed
Testing reading the data written by the previous test as halfwords
Test Passed
Shared RAM tests completed,
Testing internal loopback.
Test Passed
Testing IRQ path
Interrupt flag in device set OK
Test Passed
Testing IRQ path with no interrupt asserted
Test Passed
Testing FIQ path
Interrupt flag in device set OK
Test Passed
Testing FIQ path with no interrupt asserted
Test Passed
*** Ethernet controller tests complete ***
*** Testing PCMCIA controller and associated devices ***
PCMCIA device test starting ...
Disable IDE Registers
Test Passed
Verify controller ID
Test Passed
Bit test of Socket A register
Test Passed
Bit test of Socket B register
Test Passed
Testing socket A IRQ assertion
Test Passed
Testing socket A FIQ assertion
Test Passed
Testing socket A IRQ negation
Test Passed
Testing socket A FIQ negation
Test Passed

8-8 On-Board Software

On-Board Software
8.4 Diagnostics
Testing socket B IRQ assertion
Test Passed
Testing socket B FIQ assertion
Test Passed
Testing socket B IRQ negation
Test Passed
Testing socket B FIQ negation
Test Passed
*** PCMCIA controller tests complete ***
*** Testing parallel port ***
Testing parallel port register access
Test Passed
*** Parallel port tests complete ***
*** Testing trick box aborts ***
Testing reads from RW_Abort space:
Test Passed
Testing writes to RW_Abort space:
Test Passed
Testing reads from R_Abort space:
Test Passed
Testing writes to R_Abort space:
Test Passed
*** Trick box abort tests complete ***
*** Testing trick box cycle counters ***
Testing IRQ_CNT
Test Passed
Testing FIQ_CNT
Test Passed
*** Trick box cycle counter tests complete ***
*** Testing Flash control registers ***
Testing Flash Id
Test Passed
Testing Programming voltage
Test Passed
*** Flash control register tests complete ***
*** Calculating processor and bus speed ***
CPU core clock frequency is 213.4 MHz
System bus frequency is (CPU core frequency)/5
*** Testing COM port input and interrupts ***
Testing COMl input
.
###############################################################

Please type some characters on COMl, followed by the return key
###############################################################
>> The quick brown fox

Did the characters echo correctly (y/N)?
» y

COMl input OK.
Testing COM2 input
###############################################################

Please type some characters on COM2, followed by the return key
###############################################################

Did the characters echo correctly (y/N)?
» y

Test Passed
Testing COMl interrupt paths
################################################################

Please press the return key on the terminal attached to COMl
################################################################

Testing IRQ path
Test Passed
Testing FIQ path
Test Passed
Testing IRQ path with no device interrupt asserted
Test Passed
Testing FIQ path with no device interrupt asserted

On-Board Software 8-9

On-Board Software
8.4 Diagnostics
Test Passed
Testing COM2 interrupt paths
################################################################

Please press the return key on the terminal attached to COM2
################################################################

Testing IRQ path
Test Passed
Testing FIQ path
Test Passed
Testing IRQ path with no device interrupt asserted
Test Passed
Testing FIQ path with no device interrupt asserted
Test Passed
Testing COM2 interrupt paths
*** COM port tests complete ***
*** Testing Flash ***
Searching for bootable images in Flash
No images found
###########################################################

WARNING:

Performing the Flash integrity check will delete
all blocks that are not part of valid images

###########################################################

Should the Flash integrity check be performed (y/N)?
>> y

Flash integrity test starting
Testing block 0
Test Passed
Testing block l
Test Passed
Testing block 2
Test Passed
Testing block 3
Test Passed
Testing block 4
Test Passed
Testing block 5
Test Passed
Testing block 6
Test Passed
Testing block 7
Test Passed
Testing block B
Test Passed
Testing block 9
Test Passed
Testing block 10
Test Passed
Testing block 11
Test Passed
Testing block 12
Test Passed
Testing block 13
Test Passed
Testing block 14
Test Passed
Testing block 15
Test Passed
Flash integrity tests passed
*** Flash tests complete ***

8-10 On-Board Software

On-Board Software
8.4 Diagnostics
Surn.mary of board configuration detected

========== ============================

CPU identi ication is Ox440la100
CPU core c ock frequency is 213.4 MHz
System bus frequency is (CPU core frequency}/5
CTB configured as ARCH
SSRAM size is Ox20000
Two EDO ORA.~ SIMMs fitted (SIMM size is Ox8 Mbytes)
DRAM size is OxlOOOOOO
MAC address 08-00-2b-95-ld-7b
Jumper settings:
J2 pins 9-10 Not fitted
J2 pins 11-12 Fitted
J2 pins 13-14 Fitted
J2 pins 15-16 Not fitted
No images were found in Flash
Is this su.mrnary correct{y/N}?
» y

*** TESTS PASSED ***

(No errors detected)
*** Programming Flash image 0 (Primary boot loader) ***
*** Flash image 0 programmed ***
*** Programming Flash image 1 (Power-on diagnostics) ***
*** Flash image 1 programmed ***
*** Verifying Flash images ***

Flash image 0 correct
Flash image 1 correct
*** Flash images correct ***

=========================================================
=========================================================
Selftests complete, please reset jumpers before rebooting

On-Board Software 8-11

9
Software Utilities
This chapter describes two software utilities supplied as part of the design
database. These utilities are:
•

The Flash management utility (FMU)

•

The bootp Ethernet load utility

These programs are supplied in source form and as ARM Image Format (AIF)
files.

9.1 The Flash Management Utility
Images are programmed into Flash using the Flash Management Utility (FMU).
The executable, fmu.aif, is loaded and started using any of the ARM debuggers.
The FMU uses the ARM debugger I/O services to provide a command-line
interface. When you start the FMU, it checks for the presence of a Flash ROM,
issues a start-up message and then prompts for user input:
Flash Management Utility (1.0)
Searching for flash device
Flash found at Ox80000000 (16 blocks of size OxlOOOO)
Scanning Flash blocks for usage
FMU>

The FMU Provides these commands:
•

Help - List all of the available commands
FMU> help
FMU command smnmary:
List
- List images in flash
ListBlocks
- List how each Flash block is being used
TestBlock <block-number>
- Write a test pattern to a particular flash block
Delete <image-number>
- Delete an image in flash
DeleteBlock <block-number>
- Deletes a block that appears not to be in an image
DeleteAll
- Deletes all blocks except block 0
Progra~ <image-number> <image-name> <file-name> [<block-number>) [NoBoot)
- Program the given image into flash
Quit
- Quit
Help
- Print this help text

•

List - List the images in Flash. For example:
FMU> list
Listing images in Flash
Image 0 "BootLd
Image l "LedLoop
Image 2 "eForth:l2-feb

Length 45232 bytes, Map OxOOOOOOOl
Length 536 bytes, Map Ox00000002 Noboot
• Length 69848 bytes, Map OxOOOOOOOc

11
11

You supply the image number and name when you program the image.
Software Utilities 9-1

Software Utilities
9.1 The Flash Management Utility
The length shown is the size of the image including all headers.
The map is a bit map showing which blocks of the Flash are occupied by
the image; bit 0 of the map corresponds to block 0 of the Flash, and the
image's header is in the lowest block occupied by the image.
You optionally supply the NoBoot option when you program the image.
•

ListBlocks - List how each Flash block is being used. The :first few bytes of
the Flash block are listed. If the block contains an image, its image number
is given. For example:
FMU> listblocks
0: (Image 0) Ox2e OxOO OxOO Oxeb OxOO Ox55 Oxaa OxOO
1: (Image ll Ox02 OxOO OxOO OxOO OxeO Oxdd Ox21 Oxc6
2: (Image 2) OxdB OxlO OxOl OxOO Ox65 Ox46 Ox6f Ox72
3: (Image 2) Ox4c OxOa OxOO Ox40 OxlO Ox03 OxOO OxOO
4: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
5: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
6: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
7: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
8: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
9: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
10: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
11: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
12: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
13: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
14: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff
15: (Unused)
Oxff Oxff Oxff Oxff Oxff Oxff Oxff Oxff

•

TestBlock <block-number> - Test a particular Flash block by writing a test
pattern to the block and then verifying it. For example:
FMU> testblock 15
Do you really want to do this (y/N)? y
Writing test pattern to block 15
Reading test pattern from block 15
Flash test of block 15 worked

•

Delete <image-number> - Delete an image in Flash. You cannot normally
delete the Flash image that starts in Flash block 0 (the primary boot loader).
The only time that the FMU utility permits you to do this is if the ARM
remote debugger stub is executing from EPROM, rather than Flash. For
example:
FMU> delete 3
Do you really want to do this (y/N)? y
Deleting flash blocks: 4
Scanning Flash blocks for usage
FMU>
FMU> delete 0
WARNING: Deleting flash boot block
Do you really want to do this (y/N)? y
Deleting flash blocks: 0
Scanning Flash blocks for usage
If you are running an ARM remote debugger stub from an image other than
image 0, then you can delete that image, but the FMU will be terminated
during the delete. If you restart the system, it will execute the PBL and run

correctly.

9-2 Software Utilities

Software Utilities
9.1 The Flash Management Utility
•

DeleteBlock <block-number> - Delete a block that is not part of an image.
This may be used to clean out corrupt blocks, or blocks that have been
programmed by the TestBlock comm.and. The FMU will not allow you to
delete a block that is part of a valid image. For example:
FMU> deleteblock 15
Do you really want to do this (y/N)? y
Delete flash block 15
Scanning Flash blocks for usage

•

DeleteAll - Delete all blocks except block 0.

•

Program <image-number> <image-name> <file-name> [<block-number>]
[NoBoot] - Program the image with name <image-name> into the the Flash
as image number <image-number>. The image is read from the host from
file <file-name> (which may include a directory name). Refer to Section 9.1.1
for details on the block-number option and to Section 9.1.2 for details on the
NoBoot option. The Program comm.and will fail with an error if:
The image number is already in use
There is insufficient free space in the Flash
The specified blocks are not free
The file does not exist or cannot be opened
For example:
FMU> program 3 ledloop2 d:\users\crook\ledloop.aif noboot
Writing d:\users\crook\ledloop.aif into flash block 4
Deleting blocks ready to program:
Deleting block 4
Calculating checksum
Writing flash image header
Image is non-executable AIF file
The bootloader will copy this image to 40000000 before executing it
Writing image file
ScaTJ.ning Flash blocks for usage

•

Quit - exit from the FMU. When this comm.and is executed, the FMU will
return control to the debugger.

9.1.1 When to Specify the Block Number
By default, the FMU 'Program' command will program an image into Flash using
any free blocks allocated in ascending block order. This can result in an image
occupying non-contiguous blocks within the Flash.
When an image is a non-executable image (an image that will be loaded into
system memory by the PBL prior to execution) the PBL will load an image from
non-contiguous Flash blocks into contiguous system memory. Therefore, allowing
an image to occupy non-contiguous Flash blocks makes efficient use of the Flash
by avoiding fragmentation problems.
When an image is an executable image, it must occupy contiguous blocks within
the Flash. In general, it must also have been linked to excute from a specific
address (and therefore block) in the Flash.
Therefore, when using the FMU to program an executable image, you must
specify the block-number when you issue the 'Program' command.

Software Utilities 9-3

Software Utilities
9.1 The Flash Management Utility
When a block-number is specified, the FMU will program the image into
contiguous Flash blocks, starting from the specified block. The command will
fail if insufficient unused contiguous blocks are available.
Refer to Section 8.1 for information on the PBL, and to Section 7.2 for information
on building images that can be executed from Flash.

9.1.2 When to Specify the 'NoBoot' Option
The usual reason to program an image into Flash is so that it can be
automatically executed after reset or power-on. If the image number is less
than 7, the boot jumpers can be set so that the PBL will load and execute the
image after a reset or power-on.
Sometimes, it is desirable to have the PBL load the image into system memory
but then drop into the ARM remote debug stub. This process allows the image
to be started up under the control of the debugger, to use the 110 facilities of the
debugger and ultimately to pass control back to the debugger when the image
terminates.
If you use the the NoBoot option when programming an image into Flash, the
PBL will load the image into system memory but will not execute it; instead,
control will pass to the ARM remote debug stub within image 0.
There is no way to change the state of the NoBoot :flag for an image, once it has
been pro~J.am:med; you must delete the image imd :rep:ru151-iilll it with the NoBoot
:flag changed.
Refer to Section 8.1 for information on the PBL and the boot jumpers.

9.2 The Bootp Utility
The bootp utility provides a way of quickly loading large test programs using an
Ethernet LAN. To use it, you need:
•

Access to an Ethernet LAN

•

A bootp server

•

An IP address for your EBSA-110. It is a restriction of the bootp protocol that
this IP address must be in the same subnet as the bootp server.

Before your bootp server will respond to load requests from your EBSA-110, you
must configure it to recognize the IP address of your EBSA-110. Consult your
local documentation for details. It will probably require you to add entries to your
/etclbootptab and /etc/hosts files, for example:
in /etc/bootptab:
TWIST:ht=ethernet:ha=08002b95ld75:ip=l6.36.0.30:\
:hd=/usr/users/tester/boot/arm/:bf=flash_test.aif_dram:vm=auto:
in /etc/hosts: for TWIST as:
# Evaluation Boards
16.36.0.30 twist.reo.dec.com twist TWIST

The EBSA-110 hardware address (08002b951d75 in the example above) is
displayed when running the diagnostics. You can also find it out by running the
bootp program.

9-4 Software Utilities

Software Utilities
9.2 The Bootp Utility
The executable, bootp.aif, is loaded and started using any of the ARM debuggers.
It uses the ARM debugger I/O services to provide a command-line interface.
When you start the program, it checks the Ethernet interface and issues some
start-up messages.
The /etc/bootptab allows you to specify a default image to be loaded (fl.ash_
test.aif_dram in the /etc/bootptab example above). The bootp program loads
images into memory starting at Ox8000 by default. If you use both of these
defaults, the session will look similar to this:
Starting bootp/tftp test; initializing networking components
Am79C961 driver loaded:
Ethernet Device: 0
MAC address: 08-00-2b-95-ld-75
Please enter file name (or just CR for default)
Please enter, in hex, the load address in memory (or CR for default, Ox8000)
Attempting BOOTP.
My IP address:
16.36.0.30
Server IP address: 16.36.0.188

Loading /usr/users/tester/boot/arm//flash_test.aif_dram at Ox40000000
File loaded

If you choose to specify the filename and load address explicitly, the session will
look similar to this:
Starting bootp/tftp test; initializing networking components
Am79C961 driver loaded:
Ethernet Device: 0
MAC address: 08-00-2b-95-ld-75
Please enter file name (or just CR for default)
/usr/users/tester/boot/arm/test
Please enter, in hex, the load address in memory (or CR for default, Ox8000)
lffOO
Attempting BOOTP.
My IP address:
16.36.0.30
Server IP address: 16.36.0.188

Loading /usr/users/tester/boot/arm/test at OxlffOO
File loaded

Once the image has been loaded, the bootp program returns control to the ARM
remote debug stub.
You can use the ARM debugger to start or debug the loaded image, but you do
not have access to the image's symbolic information.

9.2.1 Variants of the bootp Program
Two variants of the bootp program are supplied:
•

bootp.aif - linked to load and run at address Ox0000.8000 (the first available
location in DRAM).

•

bootp_4.aif- linked to load and run at address Ox4000.0000 (the first location
in SSRAM).

Both versions are linked -aif -bin. They can either be loaded using the debugger
or programmed into Flash (using the NoBoot flag) and loaded automatically by
the PBL.

Software Utilities 9-5

10
Theory of Operation
This chapter provides a technical description of the EBSA-110 hardware. It
should be read in conjunction with the EBSA-110 schematic set, programmable
logic listings and timing diagrams (all of these are provided as part of the
EBSA-110 Design Database - refer to Appendix C). You should read this chapter
if you wish to gain a detailed understanding of the operation of the board. You
are assumed to:
•

Have a background in high-speed digital design

•

Have some familiarity with the ARM architecture and the SA-110 bus
interface

•

Have access to the manufacturer's data sheets for the memories and VLSI
devices used on the EBSA-110

Specific pages of the schematic set are referenced by sheet number (for example,
SHT6). The sheet number is shown in the bottom right-hand corner of the
schematic.
This chapter includes:
•

A topic-by-topic tour of the EBSA-110 schematics, including a description of
the principal buses.

•

A description of the control logic, which is implemented in two programmable
logic devices referred to as 'CTK and 'CTB'.

•

A discussion on how an expansion board could be designed for the EBSA-110.

•

A summary of the design rules used for the PCB layup and routing.

Simulation waveforms for all the important state machine sequences, together
with descriptive commentaries, can be found in Chapter 11.

10.1 A Tour of the Schematics
This section describes the principal buses in the EBSA-110 design, and then
describes the implementation and operation of each functional block, whilst
cross-referencing to the relevant pages of the schematic set.
The block diagram (SHTl of the schematics, included as Figure 2-1 in Chapter 2)
shows the VLSI devices and the connection of the principal buses, and also
provides a cross-reference to the location of any particular functional block within
the schematic set.
On the schematics, every signal has a three-letter prefix t which indicates the
origin (driver) of the signal. For bidirectional signals, the 'most important' driver
of the signal determines the prefix.

There are a few exceptions, but they should not cause confusion.
Theory of Operation 10-1

Theory of bperation
10.1 A Tour of the Schematics
10.1.1 Principal Buses
The principal buses are:
•

cpu_a[31:2] - the CPU address bus. This 30-bit bus has +3.3V switching
levels (it is not 5V tolerant) and drives the SSRAM directly. Some bits are
driven into CTA, CTB where they are used for address space decoding. The
address bus provides a longword address. Byte resolution is provided by the
byte lane enables, be[3:0]_1.

•

buf_a[29:2] - buffered address bus. This 30-bit bus is generated from cpu_a
by two 74LVT16244 buffers on SHT6. It therefore has +3.3V switching levels
but is 5V tolerant. The LVT buffers are permanently enabled. buf_a drives
the DRAM address multiplexer, the EPROM/Flash and all I/O devices.

•

cta_trick_a[2:0] - trick-address bus. This 3-bit bus is generated in CTA
on SHT8 and used solely in CTB, also on SHT8. It is a modified version of
cpu_a[24:22] - each address line is ANDed with cpu_a25. trick_a is used to
decode accesses to the PIT and to the interrupt control registers within CTB.

•

mux_a[lO:O] - multiplexed row/column address bus. This 11-bit bus is
generated from buf_a by a 74ABT162260 on SHT7. It has 5V switching
levels. It is used as the address bus for the DRAMs.

•

cpu_d[31:0] - the CPU data bus. This 32-bit bus has +3.3V switching levels
(it is not 5V tolerant) and d.i--ives the SSRAM directly~

•

buf_d[31:0] - buffered data bus. This 32-bit bus is generated from cpu_d by
two 74LVT16543 latching buffers on SHT6. It therefore has +3.3V switching
levels but is 5V tolerant. The LVT buffers are bidirectional and the control
signals are generated by CTA, on SHTS. The buffers have independent OE
control and (transparent) data latches on each port. buf_d drives the DRAMs
and the I/O data bus buffers.

•

io_d[15:0] - 110 data bus. This 16-bit bus is generated from the 32-bit cpu_d
by two 74ABT16543 latching buffers on SHT6. It has 5V switching levels.
The ABT buffers are bidirectional and the control signals are generated by
CTB, on SHT8. io_d drives all I/O devices and the ROM data buffer. In the
write direction (buf_d driving io_d) the io_d is always driven from the two
low-order bytes ofbuf_d (buf_d[15:0]). This is the data path used for all
I/O writes, and for writes to the Flash. In the read direction (io_d driving
buf_d) the value of io_d[15:0] can be latched in the two high-order or the two
low-order bytes of buf_d. This means that a 2-stage process can allow the
16-bit io_d bus to drive a 32-bit value on buf_d. This 2-stage process is used
for EPROM/Flash reads. All I/O reads return data to the CPU on d[15:0] via
buf_d[l5:0] and io_d[15:0].

•

rom_d[7:0] - ROM data bus. This 8-bit bus connects the Flash/EPROM to
the 16-bit io_d bus via a 74ABT16543 latching buffer on SHTlO. It has 5V
switching levels. The ABT buffer is bidirectional and the control signals are
generated by CTB, on SHTS. In the write direction (used for Flash writes)
cpu_d[7:0] drives rom_d[7:0] via buf_d[7:0] and io_d[7:0]. In the read
direction (used for Flash and EPROM reads) rom_d[7:0] can be latched in
the high-order or low-order byte of io_d. This means that a 2-stage process
can allow the 8-bit ROM to drive a 16-bit value on io_d. When used in
conjunction with the io_d bus latches, this process is used to pack data from
four successive ROM addresses into a 32-bit value on cpu_d (via buf_d).

10-2 Theory of Operation

Theory of Operation
10.1 A Tour of the Schematics
10.1.2 Power
Power comes onto the board through a PC-style 12-way connector (SHT21). The
board uses +5V and +12V straight from this connector. On-board regulators
generate +3.3V and +2V:
Most devices on the board use +5V power.
The +3.3V power is used for the I/O buffers of the SA-110, for the SSRAM and
for the LVT buffers. +3.3V is regulated directly from +5V using a low-dropout
regulator, a Linear Technology LT1086 (SHT20). This is an adjustable regulator
set to provide a +3.3V output.
The following devices require current at +3.3V:
•

2 LVT data bus buffers (5mA each)

•

2 LVT address bus buffers (5mA each)

•

1 quickswitch level converter (lOmA)

•

1 SSRAM (170mA)

•

SA-110 I/O cells

•

Current sourced by the outputs of all these devices

The :first elements of this list sum to 0.26A, so a 1A regulator provides sufficient
margin to account for the output drive requirements.
The +2V power is used for the core of the SA-110. +2V is regulated from the
+3.3V rail. This ensures that the +3.3V rail is stable earlier than the +2V rail
during power-on, and therefore protects the SA-110 against latch-up. The +3.3V
rail has enough power to meet the additional load imposed by the +2V regulator.
A second LT1086 is used (SHT20). The voltage output can be adjusted to +1.5V
by adding a jumper on the board. This lower voltage is used by the SA-110 at
lower core clock frequencies.
The power dissipation of the SA-110 is between 290mW and 860mW, depending
upon the core voltage and frequency. Therefore the core power consumption will
not exceed 430mA. A 1A adjustable regulator provides sufficient margin.
The +12V power is used for programming the Flash ROM and is available for use
by plug-in PCMCIA cards.
The RS232 drivers do not require +12V or -12V because they have integral bias
generator logic, as described in Section 10.1.14.

10.1.3 Decoupling
The EBSA-110 uses tantalum electrolytic capacitors for bulk decoupling of the
power rails, and ceramic capacitors for decoupling of individual I Cs.
The bulk decoupling capacitors, which are a mixture of lOuF and 4 7uF parts, are
evenly distributed around the board. They are shown on SHT19 and SHT21. In
addition, bulk decouplers are located physically close to:
•

The connector that brings power onto the board (one capacitor for +5V and
one for +12V).

•

The input and output of each voltage regulator.

Theory of Operation 10-3

Theory of Operation
10.1 A Tour of the Schematics
O.luF ceramic decoupling capacitors are located physically close to the power and
ground pins of the chip they are intended to decouple. The decoupling capacitors
are shown on the same schematic sheet as the device they decouple. Exceptions
to this rule affect the CPU (SHT3) and the programmable logic (SmS), and are
marked on the schematics.

10.1.4 Voltage Levels
The SA-110 I/O pins switch at +3.3V and are not +5V tolerant. Since many
of the devices on the EBSA-110 are +5V parts, they must be connected via
level-translation circuitry.
The SA-110 interfaces directly to th~ SSRAM. The SSRAM is a +3.3V part.
The SA-110 address bus, data bus and byte enables are all buffered using LVT
parts. These switch at +3.3V but are +5V tolerant. This allows the SA-110 to be
interfaced to the +5V parts on the rest of the board.
SA-110 outputs, such as cpu_mreq_l are used directly as inputs to the control
logic; CTA and CTB. These devices have CMOS (high-impedance) inputs with
TTL input switching thresholds which means that a +3.3V CMOS (10%-90%
swing) output can be interfaced directly. Since the inputs are CMOS, there is
no danger of a current path back from the control logic to SA-110 (for example,
during power-on).
Signais that are used as inputs to the SA-nu but which have been generated
with 5V switching levels must be level converted before they can drive the SA110 pins. This affects 10 signals and the level-conversion is performed using a
Quickswitch QS3384 (equivalent pin-compatible devices are available from Texas
Instruments and National Semiconductors). This part is shown on SHT3. On
the schematics, signals that have been level-shifted to +3.3V have a 3V3_ prefix.
For example, cta_wait_l is converted to 3V3_wait_l. The QS3384 acts as a set
of bidirectional FET switches. It introduces negligible delay (25ps). Since the
FET switches saturate, the switching level can be controlled by controlling the
saturation (supply rail) voltage. With the QS3384 powered at +4.3V t, the driven
output will be limited to +3.3V, even under light loading.
Note that these devices can also be used as bidirectional converters, since they
simply act as low-impedance switches (they introduce some resistance and have
no gain).

10.1.5 Clocks
The EBSA-110 uses 6 clocks:

•
•
•
•
•
•

SA-110 PLL input clock, osc3
SA-110 output clock cpu_mclk
SA-110 output clock cpu_mclk_I
Ethernet controller clock
Super I/O controller clock
PCMCIA controller/PIT clock

t Quality Semiconductor recommend using a diode to get this voltage drop, but experiment
showed that this did not work. The EBSA-110 uses a pair of resistors as a voltage
divider.

1o-4 Theory of Operation

Theory of Operation
10.1 A Tour of the Schematics
The SA-110 has an internal PLL which is driven from a 3.68 MHz input clock.
This clock is generated from a TTL baud-rate oscillator (SHT3) as osc3 and is
then level-shifted to generate 3V3_osc3 (SHT3). The clock circuitry shown on
SHT3 is intended to allow an off-board signal generator to be used to drive either
the PLL input clock or a full-speed test clock, bypassing the PLL. Both of these
options are only intended for chip verification.
The SA-110 generates cpu_mclk and cpu_mclk_l which are used to synchronize
bus interface operations. For the EBSA-110, this clock has a nominal frequency
of 55 MHz. The EBSA-110 uses cpu_mclk_I to clock the SSRAM and the control
logic; CTA and CTB (3 loads in total).
The SA-110 uses the signal from the cpu_mclk (output) pin to control its bus
interface unit internally. Therefore, use of cpu_mclk_l externally can cause a
skew between the bus timing produced by the CPU and the bus timing generated
by the external control logic. The solution to this problem t when using cpu_
mclk_l is to add a dummy load to cpu_mclk so that the load on both clocks is
the same. On the EBSA-110 this is achieved by adding an etch stub to cpu_mclk
(which would otherwise be unconnected) and matching the length of this stub to
the length required to route cpu_mclk_l to the SSRAM and control logic. The
etch stub is terminated in a capacitor, which mimics the pin-load imposed by the
devices on cpu_mclk.
------------------------ Note -------------------------

Designs that do not use cpu_mclk_l can leave cpu_mclk_l unconnected;
no analagous termination is required on this signal.

The Ethernet controller (SHT13) generates its clock from a 20 MHz crystal.
The Super I/O controller (SHTll) uses a TTL, 24 MHz oscillator to generate its
input clock, osc24.
The PCMCIA controller (SHT16) and the PIT (SHT19) both use a low-frequency
clock ctb_clkby7 which is generated (in CTB) by dividing the mclk by 7. The
result is an asymmetric clock with a high-time of 4 mclk periods and a low-time
of 3 mclk periods. For the supported mclk frequencies, this gives a nominal
ctb_clkby7 frequency of 7.6 MHz. This clock is not phase-synchronized with I/O
cycles.

10.1.6 Reset
Reset can be generated:
•

Automatically at power-on, by a resistor-capacitor-diode network (SHT18)

•

By a push-button (connected to J2, SHT22)

•

Under remote control, by a debug box attached to the JTAG connector (srst_l,
from J3, SHT18)

This problem arises because, for historical reasons, the bus clock is the inverse of what
you would expect; the control logic and the SSRAM must be clocked on the falling edge
of cpu_mcl.k. For low frequency designs, this is a problem that can be solved trivially
using an inverter. At high frequencies, the skew and delay introduced by an inverter
would be unacceptable.
Theory of Operation 10-S

Theory of Operation
10.1 A Tour of the Schematics
These three reset sources are combined and then debounced by a schmitt trigger
circuit to generate rst_resetJ (SHT18). This is level-shifted (SHT3) to generate
3V3_reset_l which resets the CPU. After system power-on or a CPU power-on, it
takes many microseconds for the CPU PLL to become stable. Therefore, the CPU
generates a reset output, cpu_resetJ, which is used to keep external circuitry
in a reset state until the cpu_mclk is stable*. cpu_reset_l is buffered (SHT18)
to generate buf_reset_l, buf_resetl and buf_resetO and these are used to reset
the VLSI devices on the board (SHT18 of the schematics details which reset is
used for which device). Series source terminations are used on these resets to
prevent ringing, since they potentially drive long etch lengths.

10.1.7 The CPU
The SA-110 (SHT3) has a number of configuration options. On the EBSA-110 all
of the configuration pins are wired to +3.3V or OV via outer-layer etch links on
the PCB. This allows other modes to be selected in special applications. These
options are selected by default:
•

Synchronous bus mode: the CPU generates mclk as an output. All bus
operations are synchronous to mclk, and mclk is a sub-multiple of the core
clock.

•

Fastbus mode: the address timing is pipelined.

•

E!l_h.anced bns mode: ~aP"he 1;,,e fetches ~ be wrapped, the v.Tite buffer can
merge operations and the CPU supplies byte masks.

The SA-110 core clock and bus clock frequencies can be selected using jumpers
on SHT4. The core clock can be run at any of the :frequencies supported by the
SA-110 and the mclk divisor must be set to give a maximum mclk frequency of
55MHz.

The SA-110 is always the bus master, and so it never needs to tristate its address,
data or control signals. Therefore, the abe, dbe and mse inputs are tied asserted
(via etch links).
The SA-110 powerdown capability is not used by the EBSA-110 and so the
pwrslp_l input is tied negated (via an etch link).
The high-drive critical signals :from the CPU (cpu_mreq_l, cpu_mclk and cpu_
mclk_l) have source series terminations to prevent ringing.
Chapter 11 contains detailed descriptions of the bus cycles performed by the CPU.

10.1.8 Jumpers, Etch Links, Debug Connectors and Test Points
All of the configuration options on the EBSA-110 are controlled either by plug-in
2-pin 0.1" jumpers (for options that you may wish to change) or by outer-layer
etch links on the PCB (for options that will only change under exceptional
circumstances).
Since the EBSA-110 is a debug vehicle for the SA-110 it provides a number of
connectors to help debug. The less speed-critical signals are routed to 16-pin 0.1"
pitch connectors (SHT4). These connectors are wired with odd-numbered pins
connected to OV. They are designed for direct connection to Tektronix DAS logic
state analyzer pickup pods. Speed-critical signals (where it is not acceptable to
increase the etch length for the purpose of debug) have an in-line PCB via clear
:j: It is not strictly necessary to use this signal for the EBSA-110 design, because the
power-on reset pulse will be long enough to ensure that the PLL is stable. Designs that

power-down the CPU to save power will need to use the CPU's reset.

10-S Theory of Operation

Theory of Operation
10.1 A Tour of the Schematics
of any component footprint. These vias are populated with Harwin test pins to
allow an oscilloscope or logic state analyzer to be attached easily.
The EBSA-110 schematic directory (SHTl) provides a reference to the
whereabouts of all jumpers, pickups and links. Appendix A is the single reference
point within this document for all jumpers, etchHnks and connectors on the board.

10.1.9 SSRAM Interface
The EBSA-110 uses a Micron MT58LC32K36C4 32Kx32 synchronous SRAM. This
part is pipelined and so, on reads, it takes one cycle between the address being
sampled and the read data being supplied. All operations are sychronized to
cpu_mclk_l.
The SSRAM is a +3.3V part, but its 110 is +5V tolerant. Its address and data
signals, together with the byte enables, are directly connected to the SA-110 and
use +3.3V switching. The control signals are generated by CTA (SHT8) and use
+5V switching, relying on the +5V tolerance of the SSRAM's inputs.
The SSRAM is a burst-mode part. Once given an address, it uses an internal
address counter to generate the addresses of the other three locations in the
same INT16 block. If the initial address is not aligned to an INT16 boundary,
the address will wrap at some point. The SSRAM is configured to use linear
wrapping (by negating the mode input). If it is unnecessary to access all 4
locations of the block, a new address can be loaded at any point. Loading a block
start address is always an explicit process, and is initiated by SSRAM control
inputs.
cta_oe_l, cta_ce_l and cta_adsc_l are used to control accesses to the SSRAM.
cta_adv_1 is used to stall the burst rate. cta_bwe_l is used to enable the byte
masks during write operations.
The SSRAM is never put into powerdown mode. By default, every address
presented on the address bus by the CPU will be latched into the SSRAM as a
potential read start address. This technique reduces the access latency when the
CPU performs an access to the SSRAM. Examples of SSRAM accesses are shown
in the simulation waveforms in Chapter 11.
The SSRAM footprint on the EBSA-110 is designed to accommodate either a
32-bit or a 36-bit part. It can also accommodate the next-generation 64Kx36 part.

10.1.10 Buffering
The CPU address and data buses are buffered. The low-order 16-bits of the
buffered data bus is buffered again to generate an 1/0 data bus. This buffering is
shown on SHT6. The buffered buses are described in Section 10.1.1.

10.1.11 DRAM Interface
The EBSA-110 uses +SV, 32-bit, 72-pin DRAM SIMMs and can accommodate 2
parts (SHT7). It accommodates Extended Data-Out (EDO) or Burst Extended
Data-Out (BEDO) parts. The DRAM state machine uses a software-configurable
input to control state transitions to ensure correct operation for either type of
DRAM.
An EDO DRAM is like an ordinary DRAM, except that the read data does not

tristate when CAS negates. This simple modification allows greater memory
bandwidth, since CAS can be negated (starting the CAS precharge) sooner.

Theory of Operation 10-7

Theory of Operation
10.1 A Tour of the Schematics
A BEDO DRAM has an internal 2-bit address counter. Like an SSRAM, it takes
an address and uses an internal counter to generate the addresses of the other
three locations in the same INT16 block. If the initial address is not aligned to an
INT16 boundary, the address will wrap at some point. The BEDO uses a special
write-CAS-before-RAS cycle to configure whether the wrapping mode is either
linear or interleaved. If it is unnecessary to access all 4 locations of the block, a
new address can only be loaded after explicitly stopping the current burst. (With
an SSRAM every address load is explicit, and burst termination is implicit. With
BEDO DRAMS it is the other way around; address load is normally implicit, and
so burst termination must be explicit.)
A BEDO DRAM is controlled using the usual ras_l, cas_l and we_l control
signals. BEDO DRAM chips also have an oe_l input, to facilitate page-mode
read-write cycles. This signal is not available when SIMMs are used.
The row/column address multiplexing is performed by a 74ABT162260 (SHT7).
Sequential cycles from the CPU are always performed as page-mode DRAM
accesses. For this to work correctly, sequential accesses must not be able to cause
a transition in any address line that is used for the DRAM ROW address.
The CPU cannot perform a sequential access that crosses a 2048 byte boundary.
Therefore, the least-significant bit that is guaranteed not to change during a
sequential access is a[ll]. The least-significant bit that is used as a DRAM
ROW add!-ess is a.[12!. Therefore, page-:mode DF_A_'fv.! accesses ~vill always ·wcrk
correctly for sequential cycles.
The DRAM controller always terminates a page mode cycle when the CPU
terminates its sequential access (it does not speculatively keep the page open).
Byte operations are performed by decoding the CPU byte enables (within CTA)
and using them to qualify the four cas signals during write operations.
The ras signals are decoded from CPU address lines. The decoding is a function
of the SIMM size fitted, and this is determined by monitoring the sim_id[2:1]
outputs of the SIMM. Refer to the CTA source file for details of the decoding.

10.1.12 Control Logic
The control logic is described in Section 10.2. The control logic is on SHT8.
Each of the control signals generated by the control logic has a series sourcetermination resistor, and these are on SHT9. For example, the SSRAM output
enable signal is generated by CTA as un_oe_l on SHT8 and goes through a series
resistor on SHT9 to generate cta_oe_l. The EBSA-110 PCB is designed so that
these series resistors are physically close (shortest possible etch length) to their
drivers.

10.1.13 EPROM/Flash
The EBSA-110 accommodates a 512Kbyte EPROM (which is socketed) and a
1024Kbyte Flash ROM (SHTlO). These are both mapped into the memory map
simultaneously, and they are normally decoded within the memory quadrant
where cpu_a[31:30]=[1,0]. After reset, they are also decoded in the bottom
quadrant of memory (cpu_a[31:30]=[0,0]), which allows the CPU to perform
its inital opcode fetches from ROM. There is a jumper input to the control logic
lnk_eprom_boot_l to control whether the EPROM or the Flash is decoded in
the lower half of the ROM quadrant. When the jumper is removed (the default),
the Flash will be decoded in the bottom half of the quadrant, and the system
will attempt to boot from the image in Flash. The EPROM is only necessary for

10-8 Theory of Operation

Theory of Operation
10.1 A Tour of the Schematics
manufacturing use (to allow the Flash to be programmed easily on a new system)
and may not be fitted in production boards.
Read and write accesses to the ROMs are controlled by the IO state machine
in CTB. The ROMs are byte-wide devices. During reads, the IO state machine
supplies the two low-order address lines, ctb_paka[l:O], from an intemal 2-bit
counter. It reads four consecutive locations and latches (packs) the data in data
bus buffers, so that 32-bit data is supplied to the CPU.
The byte packing is facilitated by the rom_d data buffer (SHTlO) and the io_d
buffer (SHT6). The structure of the data buses is described in Section 10.1.1. The
behavior of the byte packer is described in Section 11.15.
Writes (to the Flash) must be byte writes, on the low-order byte lane (the exact
mechanism is described in Section 3.2.4, and the waveforms are shown in
Section 11.17). It would be possible to allow 32-bit writes and then perform a
byte unpacking sequence, but this would add complexity to the hardware for no
benefit. In order to allow byte addressability of the Flash, the ctb_paka[l:O]
counter is jam-loaded with address line information at the start of a Flash write
sequence. The cpu_a[23:22] address lines are used to provide the low-order (byte
addressing) information. The selection of address lines is arbitrary (provided they
do not overlap the buf_a[19:2] used to address the higher-order address lines of
the Flash) and cpu_a[23:22] are used because they are already required in CTB,
where the paka counter is implemented.

10.1.14 Superl/O Controller
The National Semiconductor 87312Super1/0 controller (SHTll) is used to
provide two serial ports and one parallel (printer) port. This part also contains a
floppy disk controller and IDE decode logic, but these functions are not used.
The 87312 is interfaced to the io_d and buf_a buses. The device is 110-mapped,
and is mapped into the EBSA-110 self-decoding ISAIO space (Section 3.2.9).
,,
Accesses to the 87312 are controlled by the IO state machine in CTB. This state ''"
machine imitates ISA-bus 1/0 cycles and generates ctb_ior_I and ctb_iow_l. The
ISA-bus interface is self-clocked. buf_a25 is connected to the aen input of the
87312. aen is used on the ISA bus to instruct an 1/0 device not to respond to the
1/0 command signals. Therefore, it can be used as a kind of active-low chip select.
In the EBSA-110 design, it is used to differentiate between self-decoding ISAIO
space and external-decoded ISAIO space. When buf_a25 is 'l', external-decoded
ISAIO space is decoded, and the 87312 will ignore the ctb_ior_l and ctb_iow_l
strobes.
The 87312 is a byte-wide device, and is.wired to the low-order byte lane.
The 87312 interfaces to the parallel port via a set of series termination resistors
(SHTll). There are pull-up resistors on the control signals, and grounded
220pF capacitors on the data signals. The capacitors are intended to reduce
electromagnetic radiation from these signals.
The 87312 interfaces to the serial ports via a pair of Maxim MAX211E RS232
driver/receivers (SHT12). These devices have integral switch mode power
converters to generate +12V and -12V from their +5V supply rail. There are a
bank of O.luF capacitors (SHT12) that act as reservoir capacitors for the power
converters. RS232 Output signals are routed through inductors, to remove any
switch-mode noise that may have cross-coupled onto them. This is intended to
reduce electromagnetic radiation. All of the signals also have grounded 220pF
capacitors on them, intended to reduce electromagnetic radiation from these
signals.
Theory of Operation 10-S

Theory of Operation
10.1 A Tour of the Schematics
10.1.15 Ethernet Controller
The AMD 79C961A Plug-and-play ISA Ethernet controller (SHT13) is used to
provide an Ethernet interface.
The 79C961A can be configured to operate in bus master mode or shared memory
mode. In the EBSA-110 design, it is configured to run in shared memory mode.
In this mode, received packets are written to a piece of memory local to the
79C961A. Frames for transmission must be written into this memory by the
CPU. This buffer memory (SHT14) is 64Kbytes in size (it is implemented using
a 128Kbyte part, but the 79C961A is only capable of accessing 64Kbytes). The
buffer memory is on a private address and data bus, and all accesses to it are
controlled by the 79C961A. The CPU accesses this memory through a window in
the 79C961A address space, and the 79C961A performs arbitration between its
own accesses, and those performed on behalf of the CPU.
The 79C961A is interfaced to the io_d and buf_a buses. It has both memorymapped and I/0-mapped resources and is mapped into the self-decoding ISAIO
space (Section 3.2.9) and the self-decoding ISAMEM space (Section 3.2.8).
Accesses to the 79C961A are controlled by the IO state machine in CTB. This
state machine imitates ISA-bus cycles and generates ctb_ior_l, ctb_iow_l,
ctb_memr_l and ctb_memw_l. buf_a25 is connected to the aen input of the
79C961A to prevent it from responding to external-decoded ISAIO accesses.
The 79C961A generates rdy ::ind ci:m negate this signllll during accesses in order
to extend the cycle time. This mechanism is used to resolve arbitration conflicts
during accesses to the buffer memory. rdy is an open-collector signal which is
also driven by the VG468 PCMCIA controller. It has a pullup resistor (SHT9) and
is synchronized within CTB. The IO state machine uses the synchronized version
of this signal as an indication that it should extend the I/O cycle time (by keeping
the strobe asserted). When the synchronized version of rdy asserts, the IO state
machine terminates the I/O cycle by negating the strobe and then completing the
cycle normally.

The 79C961A is a 16-bit device and supports byte and half-word accesses. The
logic used to decode these accesses is described in Section 10.2.6.
The 79C961A uses an external 20 MHz crystal to generate all of its internal
clocks. Its ISA-bus interface is self-clocked. It contains some sensitive analogue
circuitry, and so has specific decoupling requirements, which are noted on the
schematics (SHT13).
The 79C961A drives four LEDs which provide an indication of network activity
and link state.
A 32-byte ROM (SHT14) is used to provide a unique ID for the Ethernet controller
(its IEEE Ethernet address). The ROM interfaces to the system buf_a bus, but
to the 79C961A private data bus, net_d. The 79C961 performs address decoding
for the ROM and generates its chip-select, net_cs_aprom_l.
The analogue circuitry for the Ethernet interface (SHT15) provides a 10-baseT
connection. The Vadem interface transformer (FL1020) provides filtering,
common-mode chokes and the equalization resistor network. This area of the
design is layout-sensitive, and we used these layout techniques:
•

Orient the Ethernet controller so that the analogue connections are close to
the interface transformer.

•

Use wide etch trace for the analogue signals.

10-10 Theory of Operation

Theory of Operation
10.1 A Tour of the Schematics
•

Route each differential pair of signals so that the etch runs parallel where
possible, and make the traces similar lengths. This maximizes the common
mode rejection.

•

Cut away the power and ground planes under the analogue signals, to reduce
noise pickup.

•

Use an isolated power plane for the chassis earth of the analogue circuitry,
and only connect to the system chassis at a single point, using a lowinductance connection.

10.1.16 PCMCIA Controller
The Vadem VG468 PCMCIA controller (SHT16) is used to provide an interface to
2 PCMCIA sockets (SHTl 7).
The VG468 is interfaced to the io_d and buf_a buses. It is a 16-bit device
and supports byte and half-word accesses. The technique used to decode these
accesses is described in Section 10.2.6. The VG468 has both memory-mapped
and I/0-mapped resources and is mapped into the self-decoding ISAIO space
(Section 3.2.9) and the self-decoding ISAMEM space (Section 3.2.8). Its connection
to the EBSA-110 is very similar to the 79C961A's interface. The differences are:
•

The VG468 requires a clock. The ctb_clkby7 is used. Because this has an
unknown phase relationship to ctb_iow_l and ctb_memr_I, the VG468 must
be configured, under software control, to operate in asynchronous mode.

•

As well as extending bus cycles using rdy, the VG468 can also truncate bus
cycles by asserting zws_l. This open-collector signal has a pullup resistor
(SHT9) and is synchronized within CTB. The VG468 is the only driver of this
signal. The IO state machine uses the synchronized version of zwsJ as an
indication that it should terminate the I/O cycle (negate the strobe) as soon
as possible, but complete the cycle normally (maintain the same address hold
time with respect to strobe negation).

•

The VG468 has a bale input, which is normally used to control an internal
transparent latch that latches high-order address lines. This is required
on PC AT systems, because the high-order address lines are only valid at
the start of the cycle. On the EBSA-110, all address lines are stable for the
duration of the cycle, therefore this signal is tied permanently asserted, so
that the latch is held open (transparent).

The VG468 directly connects to the pins of the PCMCIA sockets (SHTl 7) and
generates control signals for the power-switching circuitry (SHTl 7).
Each PCMCIA socket is supplied with +12V and +5V power via a softwarecontrolled power switch. These power switches are Linear Technology LTC1472
devices. The LTC1472 +3V3 switch is actually used to switch the +5V power,
because this makes the interface to the VG468 easier; the LTC1472 is intended to
interface to another Vadem part, and the power enable outputs have the opposite
polarity on that part.

10.1.17 JTAG Port
The JTAG port (SHT18) is only used to connect to the CPU JTAG interface. It
is designed to interface to an existing ARM debug unit. A 74ACT244 is used to
avoid directly connecting the CPU to external signals. The TTL outputs from this
device are interfaced to the CPU via level shifters (SHT3).

Theory of Operation 10-11

Theory of Operation
10.1 A Tour of the Schematics
10.1.18 Counter/Timer
The Intel 82C54 three-channel programmable interval timer (PIT) is used to
provide a refresh counter and two timer interrupts (SHT19). Channel 1 is
dedicated to generating periodic refresh requests but the other two channels are
unassigned. They can be used to generate interrupts to the CPU.
All three channels are clocked from ctb_clkby7, which has a nominal
frequency of 7.6 :MHz (refer to Section 10.1.5). The PIT outputs are effectively
asynchronous. The pit_do_rfrsh output is synchronized to mclk in CTA. pit_
irql and pit_irq2 are synchronized to mclk in CTB, if necessary.
The PIT is interfaced to the io_d and buf_a buses. The device is I/0-mapped,
and is mapped into the EBSA-110 external-decoded ISAIO space (Section 3.2.9).
Accesses to the PIT are controlled by the IO state machine in CTB. This state
machine imitates ISA-bus I/O cycles and generates ctb_ior_l and ctb_iow_I.
Since the PIT is not self-decoded, CTB generates a chip select, ctb_pit_cs_l
during PIT accesses. The PIT bus interface is self-clocked.
The PIT is a byte-wide device, and is wired to the high-order byte lane of io_d.

10.2 Control Logic
The control logic is partitioned into two programmable devices. These are called
CTA, CTB. Each is an Altera® EPM7096LC86-7. The hardware description is
expressed using the Data I/O ABEL language. Source files are provided as part
of the design database. These parts can be redesigned and reprogrammed to
meet your special needs. Refer to Appendix E for a brief tutorial on the ABEL
language.
CTA, CTB are both clocked from cpu_mclk_l and contain mostly synchronous
logic. In particular, it is a tight constraint on each that only one PLD propagation
delay is permitted between fiops.
Each device contains a mixture of state machines and random logic.
CTA contains:
•

Main state machine - main interface to the CPU. Directly controls CPU, main
data bus buffers, SSRAM accesses and the interfaces/handshakes for IO and
DRAM state machines.

•

DRAM state machine - software-selectable to generate BEDO or EDO DRAM
Cycles. Can accommodate various SIMM sizes by automatic sensing of SIMM
ID signals. Could be reprogrammed to support non-EDO DRAMs if required.

•

RFRSH state machine - takes refresh requests from external timer and
arbitrates with the DRAM state machine to make it generate a CAS-before( RAS refresh sequence.

•

2-bit Burst counter - tracks the position within a burst during SSRAM and
EDO and BEDO DRAM accesses.

•

Memory remapping state bits - cleared at reset and set once the first CPU
write has been performed.

•

Address bus decoding - generates chip selects for some devices.

•

Address bus decoding - generates RAS for the appropriate memory bank
during DRAM accesses.

10-12 Theory of Operation

Theory of Operation
10.2 Control Logic
CTA generates these outputs:
•

SSRAM control signals; cta_oe_l, cta_ce_l, cta_adsc_l, cta_advJ, bwe_l.

•

CPU cycle length control; cta_wait_l

•

MUX_A control; cta_sel_col

•

DRAM controls; cta_ras_sObO_l, cta_ras_sObl_l, cta_ras_slbO_l, cta_ras_
slbl_l, cta_cas[3:0]_1, cta_dram_we_l

•

Buffer control for BUF_D buffer; cta_bufd_wroe_l, cta_bufd_rdoe_l, eta_
bufd_rdg_l, cta_bufd_wrg_l.

•

Chip selects for the IO_D bµffer and for the EPROM, FLASH and PIT.

•

CPU ABORT signal; cta_abort.

•

The TRICK_A bus; cta_trick[2:0].

•

Handshake from Main state machine to IO state machine; cta_do_io.

•

Internal observation signals for debug; cta_obs[4:0].

CTB contains:
•

IO state machine - controls access to 1/0 devices and to the EPROM/Flash
(specifically the byte-to-longword packer). The 1/0 sub-system is based
on IBMPC peripheral chips and so the IO State machine synthesizes an
asynchronous ISA-like bus. All of the 1/0 is performed by CPU reads and
writes; there is no DMA support.

•

CLKBY state machine - generates a divide-by-seven clock for clocking some
1/0 devices. This clock is synchronous but has no defined phase relationship
with the 1/0 strobes.

•

2-bit address counter - used by the EPROM/Flash byte-to-longword packer.

•

Interrupt mask register - allows any interrupt source to be routed to the IRQ
pin under software control.

•

Fast Interrupt mask register - allows any interrupt source to be routed to the
FIQ pin under software control.

•

Fast counter - allows IRQ interrupts to be generated under software control.

•

Fast counter - allows FIQ interrupts to be generated under software control.

•

2-bit counter - used as a general-purpose resource by the IO state machine to
slow down some sequences without suffering state explosion.

CTB generates these outputs:
•

Interrupts to the CPU; ctb_fiq_I, ctb_irq.l.

•

Software-programmable outputs; ctb_soft_burst, ctb_soft_dcbr, ctb_
softo2, ctb_soft_led_l.

•

8-bit data bus for connection to IO_D; d[7:0].

•

Divided-by-7 output clock for I/O devices; ctb_clkby7.

•

IIO space memory and 110 strobes; ctb_memr_l, ctb_memw_l, ctb_ior_l,
ctb_iow_l.

•

Latch controls for the EPROM byte packer; ctb_latw_l, ctb_latb_l.

•

Data-path controls for the IO_D bus; ctb_io_wroe_I, ctb_io_rdoe_l.
Theory of Operation 10-13

Theory of'Operation
10.2 Control Logic
•

Low-order address lines for EPROM/Flash; ctb_paka[l:O].

•

Handshake from IO state machine to Main state machine; ctb_io_ack.

•

Write strobe for Flash; ctb_:fiash_wr_l.

•

Internal observation signals for debug; ctb_obs[4:0].

10.2.1 Control of CPU Bus Cycles
The CPU starts a bus cycle by driving an address and control information
(write, byte masks) on the bus, and then asserting cpu_mreq_l. The Main state
machine loops in its idle state, waiting for cpu_mreq_I to assert.
When cpu_mreq_I asserts, the Main state machine uses the high-order address
lines to determine how the cycle will be completed. The possibilities are:
•

SSRAM access. SSRAM accesses are handled by the Main state machine,
with no help from external state machines. There are separate :flows in the
state machine for read and write cycles.

•

I/O or ROM accesses. These accesses are performed by the IO state machine.
The Main state machine asserts a handshake signal, cta_do_io, to the IO
state machine in CTB. This causes the IO state machine to perform the cycle
and to acknowledge the handshake with ctb_io_ack. The Main state machine
loops waiting for io_ack. Whilst looping, it keeps cta_do_io asserted, and
controls the data bus btdrer:S. vVhen it receives io_ack, it updates cta_do_io,
latches the data in the data bus buffers (for reads) and terminates the beat by
negating cta_wait_I to the CPU. For sequential cycles (which, in this address
space, can only be ROM reads), cta_do_io will remain asserted and the IO
state machine will perform a further cycle.

•

DRAM accesses. These accesses are performed by the DRAM state machine.
The interface between the Main state machine and the DRAM state machine
uses handshakes do_dram and dram_ack, which behave in exactly the
same way as the interface with the IO state machine. Since the DRAM state
machine and the Main state machine are both in the same physical device
(CTA), these handshakes are implemented as internal nodes and are not
visible on the pins of CTA

The DRAM state machine arbitrates between performing bus cycles for the CPU
and performing refresh cycles for the RFRSH state machine. Refresh cycles
always take priority. If a refresh cycle is in progress when the CPU asserts
do_dram, then the DRAM state machine will simply ignore do_dram until the
refresh cycle has completed. This process is invisible to the Main state machine,
which simply loops waiting for dram_ack. In this case, dram_ack will arrive
later than usual, because the refresh cycle must complete first.
A similar situation occurs when the CPU performs back-to-back (but nonsequential) cycles to the DRAM. When a DRAM cycle has completed, the DRAM
state machine takes several clock cycles between delivering dram_ack to the
CPU and returning to its idle loop. It is only sensitive to do_dram when it is in
its idle loop. This ensures that back-to-back cycles cannot cause DRAM timing
parameters like the RAS precharge period to be infringed. Section 6. 7 shows
which back-to-back cycle combinations are slowed down as a result of this.

10-14 Theory of Operation

Theory of Operation
10.2 Control Logic
10.2.2 Types of Cycles
The CPU can perform read, write and lock cycles. The read and write cycles can
be non-sequential (single data beat) or sequential (multiple data beats).
A lock cycle is a read cycle followed by a write cycle. The cpu_lock signal is
asserted throughout the pair of accesses. The lock cycle is intended to allow
atomic access to a location. Since the SA-110 is the only device on the ebsarm
that can initiate bus cycles t, the cpu_lock signal is ignored.
The control state machines support sequential and non-sequential read accesses
to the SSRAM, the DRAM and the Flash/EPROM. They only support nonsequential accesses to the I/O devices.
The control state machines support sequential and non-sequential write accesses
to the SSRAM, and the DRAM. They only support non-sequential accesses to the
Flash and I/O devices.

10.2.3 Sub-Block Wrapping
The SA-110 performs wrapped accesses for some cache fetch cycles. These are
performed as 8-beat sequential reads with cpu_clf (cache line fill) asserted. The
assertion of elf indicates that the addresses may wrap during the sequential
access.
The addresses for wrapped accesses are sequenced to provide the critical longword
:first. Rather than wrap around a modulo-8 address, the addresses are wrapped
modulo-4. This wrapping order, called sub-block wrapping, is the optimum
wrapping order pattern for interfacing to memories that have a burst size of 4.
Two examples of the (seven possible) address sequences are:
first address

last address

OxOOOO. 0001
OxOOOO. 0002
OxOOOO. 0003
OxOOOO. 0000
OxOOOO. 0005
OxOOOO. 0006
OxOOOO. 0007
OxOOOO. 0004

OxOOOO. 0007
OxOOOO. 0004
OxOOOO. 0005
OxOOOO. 0006
OxOOOO. 0003
OxOOOO. 0000
OxOOOO. 0001
OxOOOO. 0002

10.2.4 The Burst Counter
Consider the case where the CPU starts a sequential read at address OxOOOO.OOOc
from the SSRAM. If a 2-beat read is performed, the CPU will expect to receive
data from locations OxOOOO.OOOc and Ox0000.0010. However, the SSRAM is a
burst device with a block size of 4. Its internal (2-bit) address counter will be
loaded with Obll for the first access and will wrap to ObOO for the second access.
This corresponds to address Ox0000.0000.
The correct behavior in this case is for the Main state machine to terminate the
burst after the :first read, and to start a new burst at address Ox0000.0010.

t There is a somewhat esoteric exception to this statement. The Ethernet controller

arbitrates for access to the Ethernet buffer memory. The CPU could read a location
and change it simultaneously with the Ethernet controller writing the same location;
even if the CPU were to perform a lock cycle, there is no way for the EBSA-110 control
logic to guarantee atomic access to the Ethernet buffer memory. Correct sharing of data
structures in the Ethernet buffer memory is architected by the Ethernet controller's
buffer ownership protocols.
Theory of Operation 10-15

Theory of Operation
10.2 Control Logic
These boundary-crossing situations are detected by a 2-bit counter called bent
(burst counter), implemented within CTA. This counter is used by the Main state
machine for tracking progress during burst transactions to SSRAM and BEDO
DRAM. The counter is controlled by the Main state machine and the count value
is monitored by both the Main and the DRAM state machines.
Two control lines, bcnt_ctl[l:O), are used to control the counter; they specify one
of three operations:
•

HOLD - leave the counter at its current value. This is the default operation,
when neither control signal is asserted.

•

DECREMENT - decrement the counter by 1. When the counter reaches zero,
a decrement will cause it to wrap around to 3.

•

LOAD_DEP- load the counter. The value loaded depends upon some other
signals, explained below.

The counter is loaded at the start of an access, using LOAD_DEP. The cpu_write
and cpu_clf signals determine what value is loaded by LOAD_DEP:
•

!cpu_write, !cpu_clf - non-wrapped read at arbitrary address alignment.
In this situation, LOAD_DEP loads the counter with the l's complement of
the low-order address lines. For example, if the low-order address is OOb, the
address is aligned to a burst boundary and the burst size is 4, so the counter
is loaded with 3. If the low-order address is Olb, the counter is. loaded with 2,
corresponding to a maximum allowable burst length of 3.

•

!cpu_write, cpu_clf - wrapped cache line read at arbitrary address
alignment or non-wrapped cache line read at block-aligned address. In
either case, the burst size will be 4, so LOAD_DEP loads the counter with 3,
regardless of the low-order address lines.

•

cpu_write, !cpu_clf - non-wrapped write at arbitrary address alignment. In
this situation, LOAD_DEP acts exactly like the !cpu_write, !cpu_clf state.

•

cpu_write, cpu_clf- write with hint that address is block-aligned and that
it is a full write (all byte masks will be asserted for all beats). This is used to
optimize the BEDO DRAM write flow. Since the address is block-aligned, it is
legitimate to load the counter to 3, so this behaves just like the !cpu_write,
cpu_clf case.

As the transaction proceeds, the 'default' command is HOLD; the count value is
unchanged. As each data beat occurs, a command of DECREMENT is issued, and
the counter decrements towards zero.

If the counter reaches zero during a transaction, it is used as an indication
that a new address needs to be loaded into the SSRAM or BEDO DRAM. The
counter state is detected in the Main state machine (for SSRAM accesses) and
in the DRAM state machine (for BEDO DRAM accesses). Once a transaction
has started, it is never necessary to reload the counter. If it reaches zero, it is
sufficient to decrement it once more, to 3. This is correct for both wrapped and
non-wrapped transactions and has three advantages:
1. It makes the decision easier.

2. It makes the counter logic simpler (no FULL LOAD required).
3. It avoids having to sample the address lines, which are slow and may not
meet the setup into the programmable logic.

10-16 Theory of Operation

Theory of Operation
10.2 Control Logic
The counter value changes on the clock after the control signals are issued. Using
cpu_clf directly in the counter avoids the need to have it valid sooner.
The burst counter logic looks like this:
BCNT := (BCNT
& (BCNT_CTL == B_HOLD))
#
([!A3,!A2] & (BCNT_CTL == B_DEP_LD) & !CLF) #
([ 1 1 l & (BCNT_CTL == B_DEP_LD) & CLF) #
{{BCNT - 1) & {BCNT_CTL == B_DECR));
I

10.2.5 The Packer Address Counter
CTB contains a 2-bit counter called paka (packer address). This counter is used
to generate the two low-order address lines for the Flash and EPROM. It is
controlled by the IO state machine.
Two control lines, paka_ctl[l:O], are used to control the counter; they specify one
of four operations:
•

HOLD - leave the counter at its current value. This is the default operation,
when neither control signal is asserted.

•

LD - load the counter with the value from two high-order address lines.

•

INCR - increment the counter value. If the counter reaches 3, an increment
will cause it to wrap back to 0.

•

CLR - clear the counter value to 0.

The counter is used during Flash and. EPROM reads, and during Flash writes.
Whilst the IO state machine is in its idle state, the counter is speculatively held
clear, by asserting CLR, in case the next cycle is a ROM read.
If a Flash write starts, LD is asserted as the sequence starts, and no further
control of the counter is required. No packing facility is provided during Flash

writes, and the two high-order address lines provided by LD contribute to form a ..
full byte address for the write cycle.

If a Flash or EPROM read starts, the IO state machine generates 4 reads to

incrementing addresses, in order to provide a 32-bit value to the CPU. The
IO state machine loops in a sequence that reads a byte from the ROM and
then increments the ROM address by asserting INCR. The two paka signals
directly drive the ROM address lines. As successive values are read, they are
latched into external buffers. The IO state machine monitors the paka count to
determine when all four bytes have been read, and terminates the data beat. For
a sequential read (such as a cache line fill), the IO state machine will continue
to assert !NCR so that the count wraps back to 0 in time for the next beat of the
sequence.
The pack address logic looks like this:
PAKA := (PAKA
& (PAKA_CTL == PAKA_HOLD)) #
( [0, 0]
& ( PAKA_CTL == PAKA_CLR) ) #
{[A23, A22) & {PAKA_CTL == PAKA_LD))
#
({PAKA + 1) & (PAKA_CTL == PAKA_INCR));

Theory of Operation 10-17

Theory of Operation
10.2 Control Logic
10.2.6 Accesses to 16-bit Peripherals
The Am79C961A Ethernet controller and VG468 PCMCIA controller are 16-bit
peripherals and support byte and half-word accesses. These devices are designed
for interfacing to PCs.
On a PC, byte/half-word accesses are controlled by the low-order address line
(saO input to the peripheral) and the signal sbhe_l. The possible combinations
of these signals dynamically accommodates PCs with 8-bit expansion buses
(the original IBM PC, the IBM XT and clones) and those with 16-bit expansion
buses (IBM PC-AT and clones). The EBSA-110 1/0 bus always mimics a 16-bit
expansion bus, and the possible options are shown in Table 10-1.
Table 10-1 Byte/Half-Word Decode Using SAO, SBHE_L
R/W

SBHE_L

07:0

015:8

Description

READ

0
1
0
0
1
0

1
0
0
1
0
0

Slave drives
Float
Slave dri\Tes
CPU drives
Float
CPU drives

Float
Slave drives
Slave drives

Low byte read

READ
READ
WRITE
WRITE
WRITE

Float
CPU drives
CPU drives

High byte read
16-bit read
Low byte write
High byte write
16-bit write

The behavior of saO and sbhe_l shown here can be implemented directly by the
SA-110, using its byte masks. buf_bel_l is connected to sbhe_l and buf_beO_l is
connected to saO.
A problem occurs in some peripherals (or some registers within peripherals)
which are only designed to accommodate 8-bit 1/0 cycles. For these accesses, the
peripheral expects to transfer data on the low-order byte lane, byte lane 0. If the
register address is even, this will work correctly. However, if the register address
is odd, the CPU will expect to transfer data on byte lane 1.
The EBSA-110 uses a trick to allow 8-bit cycles to odd addresses to transfer
data on the low-order byte lane. Instead of using cpu_beO_l to drive saO on the
peripheral directly, a modified version of this signal is used:

BYTE_BEO = CPU_BEO & !CPU_BE2 & !CPU_BE3
The effect of this modification is that cta_byte_beO_l asserts normally for byte
and half-word accesses, but is negated for longword accesses (normally all the
byte enables would be asserted for longword accesses). The negation of cta_byte_
beO_l leads to saO being asserted, causing the peripheral to perceive an odd byte
address.

10.2.7 Memory Map Switching After Reset
After reset, the ROM is decoded at address space 0, in order to provide the reset
vector. The first CPU-initiated write operation causes the address map to switch,
so that RAM is decoded at address 0.
This is achieved by 2 state bits within the CTB logic. These state bits are prime_
map and normal_m.ap.

10-18 Theory of Operation

Theory of Operation
10.2 Control Logic
Both of these state bits are asynchronously cleared at reset. When the first write
operation starts, prime_map asserts, and remains asserted. When the :first
write operation ends (cpu_wait_l negates), normal_map asserts and remains
asserted.
This two-stage process ensures that the address map does not switch part-way
through the write cycle; it switches after the completion of the first write cycle.

10.2.8 BEDO DRAM Configuration Cycles
The BEDO DRAMs must be programmed to use a linear wrapping order, before
any other accesses are performed. This is achieved using a write-CAS-before-RAS
(WCBR) cycle. During this cycle, mode information is passed into the DRAM on
the address inputs, and is latched by the assertion of ras_l. After the DRAM has·
been programmed, a CBR (with the DRAM's we_l input negated) must be used to
take the DRAM out of program mode.
CBR and WCBR cycles are performed under software control. The soft_dcbr
signal, which is controlled by the Soft register, is used to modify the behavior of
the DRAM state machine. When soft_dcbr is asserted, all write accesses to the
DRAM space will generate WCBR cycles, and all reads from the DRAM space will
generate CBR cycles.
The DRAM state machine uses the normal refresh state flow to implement the
CBR and WCBR cycles. This has the advantage that it avoids adding extra
states to the state machine. A disadvantage is that normal refreshes must be
disabled whilst soft_dcbr is asserted. At the exit of the refresh state flow, the
assignment 'DRAM_ACK := SOFT_DCBR;' in a particular state causes dram_ack
to assert during CPU-initiated cycles. If refresh was enabled whilst soft_dcbr
was asserted, the assignment would cause a pulse on dram_ack. If this occurred
whilst a CPU DRAM access was being held-off (by the refresh) the cycle would be
terminated prematurely.
sel_col is asserted during a WCBR cycle, and so the mode information is passed
into the DRAM using the column address lines, though it is latched into the
DRAM by the assertion of ras_l.

10.2.9 Address Decoding
Section 3.1 describes how the different memory and I/O devices are decoded
within the memory map. This section describes how the address decoding is
achieved.
The address decoding function is split between the CTA and CTB control blocks.
CTA uses a[31:30] and normal_map (see Section 10.2. 7) to divide the physical
address space into four quadrants:
•

DRAM quadrant. This moves according to the state of normal_map. After
reset, normal_map is negated and the DRAM quadrant is inaccessible. Once
the memory map has been switched (norm.al_map is asserted) the DRAM
quadrant is decoded when a[31:30] = [O,O]. Accesses to the DRAM quadrant
are decoded by the Main state machine which generates a handshake, do_
dram, to the DRAM state machine. This handshake initiates a DRAM access.

•

SSRAM quadrant. This is always decoded when a[31:30] = [0,1]. Accesses
to the SSRAM quadrant are completed under the control of the Main state
machine.

Theory of Operation 10-19

Theory of Operation
10.2 Control Logic
•

ROM quadrant. This moves according to the state of norm.al_map. After
reset, normal_map is negated and the ROM quadrant is decoded both when
a[31:30] = [0,0] and when a[31:30] = [1,0]. Once the memory map has been
switched (norm.al_map is asserted) the ROM quadrant is only decoded when
a[31:30] = [1,0). Accesses to the ROM quadrant are decoded by the Main
state machine which generates a handshake, do_io, to the IO state machine.
This handshake initiates a ROM access.

•

IO quadrant. This is always decoded when a[31:30] = (1,1]. Accesses to
the IO quadrant are decoded by the Main state machine which generates a
handshake, do_io, to the IO state machine. This handshake initiates an I/O
access.

Further decoding of the address space is distributed into the logic that controls
the specific accesses.
10.2.9.1 Decoding Within the SSRAM Quadrant
There is JlO further decoding within the SSRAM quadrant. The SSRAM is

multiply aliased throughout this region.
10.2.9.2 Decoding Within the DRAM Quadrant

CTA decodes 4 separate ras_l signals within this quadrant. The decode is a
function of CPU address lines, DRAM SIMM size and type (EDO or BEDO).
Because of the complexity nf this decode, fo1-!!" ;ntermen;ete pipe_ras_! ncdes :!re
generated. The DRAM state machine asserts the correct ras_I outputs by copying
the states of the pipe_ras_l nodes to the ras_I outputs.
10.2.9.3 Decoding Within the ROM Quadrant

CTA decodes the ROM quadrant to generate chip selects for the EPROM, the
FLASH and the ROM_D buffer.
This decode is a function of a[30:29] and the signal lnk_eprom_boot_I, which is
set by a jumper on the board.
When the jumper is :fitted, the system is intended to boot from EPROM and
therefore the EPROM is decoded (cta_cs_eprom_l asserted) when a[30:29]=(0,0].
The Flash is decoded (cta_cs_ftash_l asserted) when a[30:29]=[0,l].
When the jumper is removed (the default), the system is intended to boot from
Flash and therefore the decoding is reversed.
The chip selects are only asserted when a[30]=[0]. This stops the ROMs from
driving the IO_D bus during an I/O access t.
The chip selects are not qualified with a[31]. The ROMs can be decoded at
a[31]=[0] and a[31]=[1], depending upon the state of normal_map. The decode
of a[31] and normal_map is implicit in the assertion of do_io (which is a
prerequisite for a ROM access) and therefore they do not need to qualify the chip
selects.
cta_cs_anyrom_I is a chip select for the ROM_D buffer, and is asserted when
either cta_cs_eprom_l is asserted or cta_cs_:O.ash_I is asserted.
cta_cs_anyrom_l is also used as an input to CTB, where it is used to determine
whether a CPU read cycle should perform an ISAIO/ISAMEM sequence or a ROM
packing sequence.

t Actually, only cta_cs_anyrom_l needs to be qualified with a[30]=[0]. That is enough to
prevent the ROM_D buffer from driving IO_D when ctb_io_rdoe_l is asserted.

10-20 Theory of Operation

Theory of Operation
10.2 Control Logic
These three chip selects are simply clocked decodes of CPU address lines; they
are not qualified by any control signals.
The Flash write strobe is generated during all IO state machine write cycles in
which cta_cs_anyrom_l is asserted. This means that all the appropriate address
lines are implicitly decoded.
10.2.9.4 Decoding Within the 10 Quadrant
The I 0 quadrant is itself subdivided into four areas:

•

Abort space. This is decoded in CTA. Certain accesses in this space generate
. a cta_abort to the CPU. This space is decoded by a[31:28] = [X,1,0,x]. a[31]
is (X] because an abort is only generated during an I/O access (qualified by
io_ack). a[30] must be [1] to avoid generating aborts during ROM accesses
(since these also generate an io_ack). a[29:28] are used to split the IO
quadrant into four areas; the Abort space occupies the lower two of these
areas.

•

ISAMEM space. This is decoded in CTB by a[29:28] = [1,0]. The higherorder address lines are implicitly decoded since any ISAMEM cycle must be
initiated by assertion of cta_do_io.

•

ISAIO space. This is decoded in CTB by a[29:28] = [1,1]. The higher-order
address lines are implicitly decoded since any ISAIO cycle must be initiated
by assertion of cta_do_io.
The ISAIO space is itself divided into two areas:
•

Self-decoding space. This is the subset of ISAIO space for which
a[25]=[0]. Self-decoded I/O devices are inhibited from responding to
addresses in which a[25]=[1] (refer to Section 3.2.9 and Section 10.1.14).

•

External-decoded space. This is the subset of ISAIO space for which
a[25]=[1]. This space is used to access the PIT, and to access the Trickbox
registers within CTB. All external-decoded devices are selected by
decoding cta_trick_a[2:0]. cta_trick_a[2:0] is generated in CTA by
using a[25]=[1] to qualify 3 other arbitrary address lines that are already
used in CTA. Accesses to trickbox registers 1-7 in ISAIO space decode
a[25] explicitly. Trickbox register 0 is an exception, since cta_trick_
a[2:0]=[0,0,0] does not guarantee that a[25]=[1]. Trickbox register 0
space is used to access the PIT, and it is decoded in CTA, using a[25:22] =
[1,0,0,0], to generate the cta_cs_pi(_I.

10.3 Timing Analysis
Worst-case min/max timing analysis was performed on the EBSA-110 design
using Chronology's TimingDesigner® tool. The source files and plots of this
analysis are supplied as part of the design database.

10.4 Expanding the EBSA-110
The EBSA-110 can be expanded by adding a mezzanine card which plugs into the
debug connectors.
These connectors supply all the signals required to interface logic to the I/O bus,
in ISAMEM or ISAIO space. The signals include rdy and zws_l, so that the cycle
length can be controlled.

Theory of Operation 10-21

Theory of Operation
10.4 Expanding the EBSA-110
Power is not supplied on these connectors, and so a separate power connector will
be required from the system's power supply. The connectors do supply the OV
reference (ground return) for signals on the connectors.
The debug connectors include 5 unassigned signals from each of the two
programmable logic parts. These are cta_obs[4:0] and ctb_obs[4:0]. By default,
these signals are used to provide observability of internal state information. They
could be reassigned to some other purpose.
The debug connectors also provide access to usr_irq, which is a spare interrupt
reserved for use by an expansion board. It is an active-high signal and has an
associated pull-down resistor.
The pinout of the debug connectors is shown in Section A.5.

10.5 The Printed Circuit Board
The EBSA-110 printed circuit board is a 6-layer controlled impedance board using
0.005" track and 0.005" gap routing rules. The mechanical drawing of the board
shows the board's layer construction and dimensions. The mechanical drawing is
supplied as a PostScript® file as part of the design database, see Appendix C.
When the board was routed, all nets were daisy-chained except for the data and
address buses, which were bussed. The clocks and strobes were hand-routed first,
to minimize the etch lengths.
Many of the clock and strobe nets include series resistors. These act as source
terminations to reduce ringing on the signals. In all cases, the series resistors are
placed so that the etch from the signal's driver to the series resistor (nets with
the un_ prefix) is as short as possible.

10.6 Design Improvements
This section describes some areas where the performance or implementation
efficiency of the design could be improved. These opportunities arise with the
benefit of hindsight.
•

Worst-case timing analysis of the design with characterized CPU timings
indicate that it is possible to use slower pipelined SSRAMs (the board
currently uses -6 parts, but -8 parts would work correctly).

•

Worst-case timing analysis of the design with characterized CPU timings
indicate that it is possible to use non-pipelined SSRAMs (12ns or faster). This
would allow one stall cycle to be saved on some SSRAM reads, but would
require modification to the main state machine.

•

The LVT data bus buffering could be implemented using cheaper unlatched
parts; the latches were necessary in an earlier version of the design but are
not necessary in the :final design.

•

Some DRAM accesses could be speeded up by having CAS negate on the
falling clock (so that CAS is asserted for half a clock period, rather than a
whole clock period). This would allow CAS to assert on successive clock edges;
at the moment, CAS can only assert on alternate clock edges.

10-22 Theory of Operation

11
Simulation Waveforms
This chapter provides cycle-by-cycle descriptions of a number of simulation
waveforms which show the major functions of all of the state machines and
control logic on the EBSA-110.
These descriptions are intended to be read sequentially - detail presented in early
sections is not repeated in later sections.
All of the waveforms in this section are included (in PostScript format) in the
design database. When printed separately, they will be slightly larger than
they are reproduced here (since these pages have margins). Each of them
can be reproduced in a simulation environment, by running the specified test
scripts on the design. The whole set can be produced using the simulation script
'do_specwave.cmd'.
All of the simulations show a system clock with a period of 18. 75ns.

11.1 automap
This waveform, shown in Figure 11-1, was produced using the simulation script
'do_automap.cmd'.
This simulation shows the way in which the address map decoding changes
after reset. After reset, the EPROM/Flash is decoded in the first and the third
quadrant of the physical address space (base addresses 0, OxS000.0000). The first
write performed by the CPU (address is don't care) causes the address map to
change so that the EPROM/Flash is no longer decoded in the first quadrant; the
DRAM is decoded there.
The waveform shows the sequence:
1. 2-beat sequential EPROM read; shows that EPROM is decoded at address
OxS000.0000 (the EPROM packing sequence is described in Section 11.15).
2. 2-beat sequential EPROM read; this shows that EPROM is also decoded at
address 0.
3. Write to address 0 (performed as a write to the EPROM).
This write causes the address map to change. The write does not affect the
contents of the DRAM.
Notice that prime_map asserts at the start of the write cycle and that the
asserted state of prime_map causes normal_map to assert at the end of
write cycle (when cta_wait_l negates). The assertion ofnormal_map causes
the address map decoding to change.
4. Write to address 0 (performed as a write to DRAM). This shows that the
address map has now changed for write cycles.

Simulation Wavefonns 11-1

....
....
rt,
(/)

3·

::J

gooooooo

8ooooop4

BYTES

;

00000000

::::===:J

poooooo4

==::J

:J: 00000000

::J

rmH_A

UOl-t_I>

00000000

~~~~~~~~~~-~~

0 0

eoooooo;i

00000000

Cl'U_Cf,I·'

f:'l'A_W/1I'l'_f,

Cl'U_l.fJCK

n :
I

Cl'll_WH1'1'1·:

M/\lll_!il·I

""I

00000004

........

·*--'"""'..;..;..~

,,3

(5)

m -,

.c.

me-mm~~

; .,-

.'.

DllAH_SM
Rl•'H~ll_!:l-t

;

r8l

•

lDlllI

.h._;_r--1

?·

IO_!:U
C'l'J\ \C'l'/\ \ l'Ull.JH_H/\I'
C'I'/\ \C'l'A \llOUMAl._l·fAP

:·r11_Arn;c_L
'C'l'l\_UWE_t,
C'l'A_Ct-.:_I,

lc'r/\_Auv_r.

; 1:::£

T:lf
-.-

lr.lf

C'rA_Ol-!_I,

[!X

--.,-

j:c

OCll1'
UCll'f_C'l'f,

:>K:

r.i

C1'/\ \CTI\\ OO_l>RAM

CTI\ \CTA \ORAM_ACK
jC'rA_OUl•'D_~·IROF._I,

:c'l'A,_OUFO_ROOE_r.

CTA_llUl·'O_ROO_I,
CTA_ntWl>_WRG_t,
CTA_RAS_f,

,.-------

·-I'

CTA_CAS_I,

S1.

:J.(

·~

][

OlJO

• 000

::J[

RiR
..
F

'.lr

CTA_SEt._cot.
MUX_A

JO[

(!X'

.I!

J.L.j

-~q~

prA_DRAH_WE_l~

!cTU_CLKBY7

CTB_IO_ACK

lcTD_l.ATW_I•

CTB_(,/\Tll_L

l'AKA

c·ru_IO_ROOICL
tu

.... ct
Oo

_____,__ _ ___,

ir:

r.-1

automap

T (CPU_MCLK)

Tirre

(Seconds)

~--~-----UL----'

-'(/)

I» 5.

~
:

~---.

:::::::::::J

--·

Cl>

~.~.~~~

C'l'lJ_MnEv_1.

r:po_m·:v

(

. 6

lllJF_O

IO_ll

aooo)looo

BUF_A

ca·c

CPU_HCLK_L

c
~

o·

.,,

CPU_HCLK

3 :s

a<0
""I

3t/)

Simulation Waveforms
11.1 automap
5. Write to EPROM at address OxS000.0000; this shows that the EPROM is still
decoded in high address space.
6. Read from address 0 (performed as a read from DRAM). This shows that the
address map has now changed for read cycles.

11.2 ss_wcrd
This waveform, shown in Figure 11-2, was produced using the simulation script
'do_ss_wcrd.cmd'.
This simulation shows an SSRAM worst-case read sequence. It performs a 4-beat
sequential read starting at address Ox4000.0008. Reads are performed from
addresses Ox4000.0008, Ox4000.000c, Ox4000.0010 and Ox4000.0014. The :first
two locations are in one SSRAM burst block and the second two locations are in
the next SSRAM burst block. Therefore, the Main state machine must cross an
SSRAM block boundary during the access.
The waveform shows the sequence:
1. The first address (Ox4000.0008) is loaded into the SSRAM. It is the address
of the third location in a block. The burst counter, bent, loads the value 1,
to show that there is 1 more piece of data available in this block. The bent
value is the l's complement of the low-order CPU address lines.
2. The state machine introduces 1 stall cycle to account for the access latency of
the SSRAM.
3. Two beats of data are returned to the CPU, back-to-back (Ox8899.aabb,
Oxccdd.eefi) on adjacent clock cycles.
4. bent reaches 0, forcing a new address (Ox4000.0010) to be loaded into the
SSRAM. The access address is now aligned to a block boundary, so bent is
decremented and wraps back to 3.
5. The Main state machine introduces 2 stall cycles; the :first allows the address
to be latched in, the second accounts for the access latency of the SSRAM.
6. Two more beats of data are returned to the CPU, back-to-back (Ox1122.3344,
OxOOll.2233).
7. The cycle ends because cpu_mreq_l negates, and the Main state machine
goes back to state 0 (idle).

11.3 ss_wcwr
This waveform, shown in Figure 11-3, was produced using the simulation script
'do_ss_wcwr.cmd'.
This simulation shows an SSRAM worst-case write sequence. This is a 4-beat
sequential write across an SSRAM block boundary; the write equivalent of
ss_wcrd.

Simulation Waveforms 11-3

.I.
.I.

·~·

BYTES

(J)

3·

UUl·"_I>

::I

ROM_A

~
<

l<OM_I)

to_o

40006068

c1•u_r·nmo_1,
;po_c1.1··

r·rA_Wt\l'l'_I,
lcl'U_l.1><'.K

ICPIJ_WH l'l'I,:

00008

•

[O_!:M

!C'l'A \C'l'A \PR IMB_MAI'

IC'l'A \C'r/\ \llOlu.tAI. MAJ•

: (4)

: I

C'l'A_Al>S<:_r.

Ic·rA_uw1-:_1.

• _x ___!•

onoro

Oi"

IU'IH!ll_m.s

~-- I

•

l':'l'A_CICl1

:!1'A_AOV_f,

:c·rA_mi:_r.

I
::!::::](
2

ocrrr

nc11·r_c·r1.

: X

x
: I
•

•u
:

•X:

:x:=::::;::==:::;p==:';::=:::::;;x:;::==:;:::=~1:=:::::==:=:~L2~;;:

'CTA\CTA\IX) ORAi-i

lCTA\CTA\D,;14_ACK

CTA_DUFD_WROE_L

r:TA_DUFO_ROOE_L
CTA_UUPD_ROO_L

ICTA_DUFD_WRG_f,
p

iCTA_RAs_r..

•

rTA_CAS_f,
CTA_SEL_co1.

!MUX_A

. :x:=:::!!!!

TA_ORAM_WE_I,

CTB_Cl,KBY1

ICTA_DO_IO

CTR_IO_ACK
I

!C'rD_t.A·rw_1,

...

i<~·rn_1.M·11_1,

PAKA

!:::t

:i 0
n :::s
:E :::e

= :=.. : . :~·": g: ., ; '1 ~I
'.(

l>HAM_!:t·I

..k= .

. _ __:

~=- ~x _x •

•

+· :

MAllJ_rn.t

c=x:=x=x;::

•

--·~··.

l
1:t•IJ_!H·:\'

!/)

. x:::x::::::t

BUF_A

aa·

!Q.

..
ii
·o· ii. , . , ,"'
~"'!""0 m~ ~~= I.UL .liS§s: ~ ~i

CPU MCLK

I~PU_MCLK_L

ICTH_IO_ROOB_I,

s.su

s.ssu

iTICPUJICLKJ

Tim•e (Seconds)

5.611

ss_wcrd

L ·!1>

CPU_Hcl,K

·J

:l. (3J,

CPU_HCLK_L

BYTES

xx~xxx~ •.l,

OUF_A

·_I

:.,::

..I!
:I'

, 80!191\l\Ull

. xX·

_I; ~~XX)<_X

•uuy~

·~008

J:~XXXXX~

_I.

_I:

C{;DDt:t:n··

:.x
:.x
:.x

'""""~

~··

.:.x

x~xxxx

.:..::
·_I

1 ·<SJ

·:.X

:.x

ca·c"11

··~·
~·

~·~33

·_I

·:x

Y.XXXX

'"t

(I>

....
....

:x :.x

400~14

I
w

BUl·'_D

"~'"

IO_!)

HO!·lji

xxxxx

00000:

xxxxx.

00008

. xxxxx

;OOO!!:

·I

fu1J.1_1l

Ill
Ill

(10014

':e

Cl'U_MIU::(J_I.

Cl'll_!:EQ

.c:,,.

Cl'll_f,OCK

.c:,,.

t·1>11_~·m1·1·1-:

.:'>.

Cl'IJ_1:1,F

.c:,,.:

"-...'
.:'>.

'"t

C'l'/\_NA l'l'_I.

M/\Jtl_!>f.I

::!

JJO

l>HAf.t_i;l·I
ltFH~;tl_~iH

•O

IO_!;t·f

;_<>_

--- -

CT/\\C1'/\\ l'Hll·U-:_MAP

'C'l'/'1. \C'l'A \WllH-ll'll._M/\I'

C'l'/\_/\DSC_t.

_J:

g
cTA_m·m_t.

CTJ\_cg_J,

CTA_OI•:_I.
UCU'I'

UCflT_CTI,

id
s:1

_J.

CTJ\_Al>V_J,

<4}

( 2,)

l.'

·J_

:x:

..l.

'::!:

C'rA \C'r/\ \ OO_DR/\M
CT/\ \CTI\ \DR/\H_/\CK
CT/\_ou1~o_WROt:_1.

CTA_OUl:i>_nnot:_1.
CTA_BlJFD_RDG_t,
CTA_OlJFO_WIW_J,
CTJ\_HAH_I,

CTl\_C/\S_I.

cT/\_sm._co1.
MUX_/\

:.X·

:.x

xxx

CT/\_DH/\H_...m_t.

(/)

CTB_Cf.KOY'/

CT/\_00_10

~
0
::i

-~
0

3C/l

......
......

:.x

xxx,

·I o~;x:

·~

::x;: 000 :];

,xxx

CJ)

;....
....
c:r
..a. :::s

CTB_IO_ACK

c:TO_l,/\TW_l,
CTA_J,ATD_(,

•o

l'Af</\
CTH_lO_RIXH·:~I•

5. 7.6U

S. 2'/u

5 .::!:Ou

5.7.911

5. Ju

T(CPU_HCLKl

Time (Seconds)

3·

5.Jlu

5, 32u

5. )Ju

5. 34u

5.:

ss_wcwr

w:E
0~
0 CD

'::C> O'
..,
::
.., 3
0

Simulation Waveforms

11.3 ss_wcwr
The waveform shows the sequence:
1. The :first address is loaded into the SSRAM, and bent is loaded as before. At
this stage, the cycle is identical to the read cycle, except that cta_wait_l is
not asserted after the address is latched.
2. In the cycle after the address has been latched, the SSRAM read cycle is
converted into a write cycle by the assertion of cta_bwe_l to the SSRAM. The
:first write data (Ox8899.aabb) is latched.
Notice that the address is valid at the time that the write data is latched into
the SSRAM. The address itself is not required, but the byte masks (which
have the same timing as the address) are required; they drive the SSRAMs
directly (asynchronously; the synchronous write enable, cta_bwe_l, qualifies
them).
3. In the next cycle, the second write data (Oxccdd.eeft). is clocked into the
SSRAM. At this time, bent has reached 0, so a new address must be loaded
into the SSRAMs for the next beat of the write.
4. A new address (Ox4000.0010) is loaded into the SSRAM, simultaneously
with the third write data (Ox1122.3344). This uses a different combination
of control signals to the SSRAMs. (At the start of the cycle, the address was
loaded with cta_bwe_l negated, and no write data supplied. This time, the
address is loaded with cta_bwe_l asserted, and this allows write data to be
supplied at the same time.)
5. The fourth write data (OxOOll.2233) is loaded into the SSRAM.

Notice that the whole cycle occurs without the addition of any stall cycles (eta_
wait_I is never asserted).

11.4 ss_rdwrap
This waveform, shown in Figure 11-4, was produced using the simulation script
'do_ss_rdwrap.cmd'.
This simulation shows a CPU cache block fill from SSRAM. This is an 8-beat
sequential read and shows the sub-block wrapping performed by the CPU.
The CPU cache block size corresponds to eight 32-bit reads on the bus. Since
burst memories (both SSRAMs and BEDO DRAMs) have a block size of 4, the
CPU presents the addresses wrapped to a block size of 4. For example, if the
:first address was 1, the address sequence will be: 1,2,3,0,5,6,7,4. Notice that the
second block starts with the same offset into a block as the :first.
The CPU distinguishes a cache read (the only time that a sequential cycle has
non-sequential addresses) by the assertion of cpu_clf (Cache Line Fill). The
control logic uses this signal to force bent to load to 3, irrespective of the value of
the low-order address lines.
The waveform shows the sequence:
1. The read starts with an SSRAM address load of Ox4000.0018, and a stall
cycle is introduced, as before.

11-6 Simulation Waveforms

CPU_MCLK

CPU_llCLK_L

•

BYTES

•

• 4 000 ~6

•

.
•

•

000

4000 0, 4
I'

ca·"T1c
Cil

.....
.....

40000 08

BUf'_ll.

.rrnnJ.:

<M ol'11il4

, ••

.
•

./:..

BlW_D
ICl_ll

!(OJ·l_A
H11M_ll

<:l'IJ_f.\IH.:V_I,

Cl'U_~:E1,,1

l'f>ll_{'l,F

'tS

C'l'A_\'.'Al'l'_I,
Cl'tl_l.OCK

Cl'IJ __WHITI·:
J.IAill_!:l·I
l>UAJ.l __ ~:t·I

IH-'HSll_SM
1n_sM
IC'l'/\_Al>SC_f,

C'J'/\_BWE_I.

c1•A_cr._1,
C'rA_Al>V _I,

CTA_Ol·:_I,
DCfl'I'

BCllT_CTlo
CTI\ \CTI\ \l)O_ORAM
C'I'/\ \C1'/\ \Olt/\1-1_1\CK
CTA_BUFO_Wlt01·:_1,
CTl\_UUFO_RIXlE_f,
CTA_DUFD_ROO_f,
CTl\_OUl-'D_WRO_I.

::r

CTA_H/\S_L

CTl\_CAS_t,

iCTl\_SEl._cm.
;MOX_A

000

• xxx

xxx

CT/\_Olt/\H_Wl.;_f,

C'l'll_CJ,KB't1

CJ)

C1'/\_00_IO

(/)

CTB_ro_ACK

CTll_[,/\'l'Jl_f,

3·

~
0

r
~

..I.
..I.

.ti

3·
c

C'i'IJ_Lh'l'W_I,

-~
-o

P/\K/\

CTB_IO_ROOJ;;_f,
iCTB_IO_\.'IROE_J,

~ :s

CTR_Hl'.:HR_f,

5. 7u

5 .au

5. 75u

T (CPU_MCLK)

Time

(Seconds)

5. B5u

5.9u

ss_rdwrai::

I.., <
CD

c.~
.., o..,

"C fl)

Simulation Waveforms
11.4 ss_rdwrap
2. All four locations in the block are read, with no further stall cycles being
introduced. The addresses are Ox4000.001c, Ox4000.0010, Ox4000.0014.
The read data is Ox6666.6666, Ox7777.7777, Ox4444.4444 and Ox5555.5555.
Because of the magnification of the waveform, the address values cannot be
seen, but it is clear from the data values that non-sequential locations are
being accessed.

3. bent reaches 0 and is decremented to 3.
4. Two stall cycles are introduced; the first is needed to get the CPU address
stable to meet the setup time into the SSRAM. The second accounts for the
access latency of the SSRAM. The new address, Ox4000.0008, is loaded into
the SSRAM.
5. The next four locations in the block are read, as before, with no further
stall cycles being introduced. The addresses are Ox4000.000c, Ox4000.0000,
Ox4000.0004. The read data is Ox2222.2222, Ox3333.3333, Ox0000.0000 and
Oxllll.1111.
Notice that epu_clf remains asserted throughout the cycle, and that a total of
three stall cycles are introduced.

11.5 ss_rdall
This waveform, shown in Figure 11-5, was produced using the simulation script
'do_ss_rdall.cmd'.
This simulation shows a number of read sequences that exercise all the
transitions in the read path of the Main state machine. In particular, it
shows all the bent counter decrementlload transitions.
Although the scale of the waveform does not allow the individual CPU address
and data sequences to be identified clearly, it does show all the Main state
machine transitions and control of the bent counter..
The waveform shows the sequence:
1. 9-beat sequential read starting at the last address in a block. This causes
three address loads to the SSRAM. One data beat is read at the first address,
and four data beats are read at the second and third addresses.
In the Main state machine, this causes the state transitions:
hidle-hrdl-hrdla-hrd2, hrdl-hrd2-hrdl-hidle

2. 2-beat sequential read starting at the last address in a block. This causes 2
address loads to the SSRAM. One data beat is read at each address.
In the Main state machine, this causes the state transitions:
hidle-hrdl-hrdla-hrd2-hrd3-hidle

3. 4-beat sequential read starting at the second address within a block. This
causes 2 address loads to the SSRAM. One data beat is read at the first
address and three data beats are read at the second address.
In the Main state machine, this causes the state transitions:
hidle-hrdl-hrd2-hrd3-hidle

11-8 Simulation Waveforms

.,,

'!CPU MCLK

clS'
c

:PU_HCLK_L
XXXXXXX\I

BYTES
D

llllllll\

BUF_A

XXXXXXX\I

DUP_O

'.ZZZZZZZ.\

IO_ll

Z?,ZZ\11

NOM_A

XXXXX\11

IWM_f)

Z1.\ll

cl•U_MHl·:O_I,
1

CPU SP.()

lcpu=c1.1~

'C1'A_W/\I'r_f,

lcl't1_1.oeK

x
x

Cl'll_Wlll'rl•:

'H/\Ill_BM

1\11

l>H/\M_SM

00\11

n111rn11_mt

0\11

IO_HM

0\11

. ....

X\11

....

0
,0

...

r-1

........,

-,-.

........,

r-1

,-,

r-1

..,_.,

r-1

........,-

. '==

;cT/\_ADSC_r.
'cT/\_HWt::_r.
c•rA_CE_L

CTA_ADV_I•

'CTA_OICl1

DCllT

0\11

DCUT_C1'L

1\11

:cTA \CT/\ \OO_OR/\M

CTA\CTA \OR/\H_J\CK
I.CTA_OUFll_WROE_I,
;cTA_DUPD_ROOE_L

iCTA_DUFD_RIJG_t,
cTA_uum_wno_L
1

ICTA_RAS_I..

F\11

ICTA_CAS_I.

P\11

;CTA_SEl._cor.
f4UX_A

000\11

ICT/\_ORAM_WE_J,
CTD_CLKUY7

,CTA_OO_IO

!'o.
3
c

m;
g
~

IC'l'H_IO_J\CK
1CTD_l,ATW_L

ICTB_LATll_J,

PAKA

0\11

6'
"" ::s

ICTB_IO_ROOE_L

TD_IO_WROR_J,
[CTDJIEHll_I,

~
0

~
........
cb

3·
i

T (CPUJICLK)

6. tu

6.2u

6.3u

5.8955u

Time (Seconds)

6;4u

6.Su

6.6u

ss_rdall

(I)
(1)

1 CD

~a'
CL~

I» 3

=(I)

Simulation Waveforms
11.5 ss_rdall
4. 1-beat sequential read starting at the :first address in a block. This causes a
single address load.
In the Main state machine, this causes the state transitions:
hidle-hrdl-hidle

5. 2-beat sequential read at the :first address in a block. This causes a single
address load
In the Main state machine, this causes the state transitions:
hidle-hrdl-hidle

11.6 ed_wcrd
This waveform, shown in Figure 11-6, was produced using the simulation script
'do_ed_wcrd.cmd'.
This simulation shows an EDO DRAM page-mode read sequence. This performs
a 4-beat sequential read starting at address Ox0000.0008. Reads are performed
from addresses Ox0000.0008, OxOOOO.OOOc, Ox0000.0010 and Ox0000.0014. Since
the EDO DRAM is not a burst device, each read cycle to the DRAM is performed
individually. ras_l remains asserted throughout the access since all the addresses
within the sequential read must be on the same DRAM page.
The waveform shows the sequence:
1. The CPU asserts cpu_mreqJ to start the cycle.
2. The Main state machine decodes a DRAM access and asserts do_dram to the
DRAM state machine.
3. The DRAM state machine moves out of its idle state.
4. cta_ras_l asserts to the appropriate DRAM bank, latching the row address
(shown as mux_a on the waveform).
5. cta_sel_col asserts to route the column address to the DRAM.
6. cta_cas[3:0Ll assert. For a read cycle, all four cas_l signals are always
asserted. Since this is an EDO DRAM, cas_ is only asserted for a single
cycle, to allow the cas_l precharge to start as soon as possible.
7. The DRAM state machine generates dram_ack as an indication to the Main
state machine that the access has completed The Main state machine leaves
do_dram asserted, because cpu_mreq_l is still asserted. The continued
assertion of do_d.ram keeps the DRAM state machine in a loop, with ras_l
asserted.
8. DRAM read data has propagated through the buffers to the CPU data bus.
------------------------ Note ------------------------

These simulations do not include DRAM models, so the read data is never
shown.
9. The Main state machine negates cta_wait_lJor one cycle, so that the CPU
will sample the read data.

11-10 Simulation Waveforms

ICPU_MCLK
1CPU_MCLK_L

A
BYTES

~0000008\
0\11

Z?.1.Z?.?.?.?.\I

BUF_A

00000000\

IUW_U

ZZZZZ?.ZZ\i

10_1>

?.ZZ?.\11

RCllCA

f)(J000\11

fl:llH_ll

ZZ\11

Cl'll_HIU.:C,,1_1,

Cl'IJ_Sl·:Q

ca·c'11

'Cl'lJ_Cl.I"

C'l'l\_W/,I'l'_I.

·l!l

.Il.ll

:n:n

66i'Ji'Ji'HiiiC

llil

.x:::x

oool;c

I~!

R(l) : I :

MAllJ_SH

11\11

OUll.f-L!JH

0::?\11

1t11um1_m1

0\11

lO_Sl·I

0\11

iJlxJunnn~

u
liOfiooolO

;

--.,-

:u:rr

CiJ

[

·l.!...l.

;
00010

....
....
J,

D
D

l._

_o_
_o_

l:l•ll l.f>CK

!c:l•ll=WRJ'l'IO:

• :x::!I:

.--,

(3)

~
00

x 01 LI:!! JC .o3 I

X 64

S oi

--.---.--

116>
.o3

X 04 $

X 01 I

06.

X 64 I

:
08

J_n

IC'l'A_Am:c_J.

'c1·11._nw11,_1.

1C'l'A_c1-:_1.
CTl\_Al>V_J,

I
C1'A_Ol-':_I,

RCll'f
llCtlT_CTL
CTA\CTA\00 l>RAH

IC'l'I\ \CTA \DH~H_ACK
CTA_IJUfo"D_WROll,_f,

ICTA_DUPD_RDOF._I.
CTl\_HUl•'l>_ROO_I,
CTA_IHJF1>_w1m_1.

:c1•A_RAS_f,

icTA_CAS_t,

ICTA_SEl.._Cot,
MUX_A
ICTA_DRAM_WH_f,

1CTD_Cf,KBV7

CTA_IX>_IO

(/)

3·
c

:E
~

3·

CTU_IO_ACK

C'l'IJ_l.ATW_L

a6'

;CTU_L/\'fD_I,

PAKA

lcTn_to_RooM_t.

.... :J

lc·1·u_1o_wao1-:_1.
lcTU_HEHR_f,

~
........
.!,.
....

9,·1u
ITICPU_MCLK)

9.Bu

9.680

Time (Seconds)

9.9u

ed_wcrd

lOu

CD <

a.!!.

l:e ~

i''

(I)

Simulation Waveforms
11.6 ed_wcrd
10. The CPU generates the address for the next beat of the read cycle.
11. The DRAM state machine generates cta_cas[3:0]_1 to latch the new address.
The rest of the read access proceeds as before.
12. The CPU generates the address for the third beat of the read cycle.
13. The CPU generates the address for the fourth beat of the read cycle.
14. The CPU negates cpu_mreq_l because the current address is the final beat
in the sequential access.
15. When the Main state machine samples dram_ack asserted, it negates
do_d.ram because cpu_mreq_l is now negated.
16. Once the Main state machine has negated cta_wait_l for the :final data beat,
it goes back to its idle state.
17. The DRAM state machine cycles through an additional state sequence before
returning to its idle state. This prevents it from responding to a new request
from the Main state machine until it has satisfied the DRAM ras_l precharge
requirement.
This sequence takes 356.25ns (the same as the time for the BEDO), timed from
the clock edge on which cpu_mreq_l asserts to the clock edge on which the CPU
detects the negation of the final eta_wait_I.

11.7 ed_wcwr
This waveform, shown in Figure 11-7, was produced using the simulation script
'do_ed_wcwr.cmd'.
This simulation shows an EDO DRAM page-mode write sequence. This performs
a 4-beat sequential write starting at address Ox0000.0008, and is the write
equivalent of ed_wcrd.
The waveform is very similar to ed_wcrd. The notable differences are:
1. The write data for the first beat of the write becomes valid on the buffered

data bus.
2. At the DRAM, a write is indicated by the assertion of cta_dram_we_I.
3. When cas_l asserts, the byte enables from the CPU determine which of
cta_cas[3:0]_1 assert. This provides byte-resolution on writes.
4. The first data beat is terminated, and the CPU drives write data for the
second beat of the write.
5. During a sequential write, cta_dram_we_l negates for a single cycle as the
address transitions across an INT16 boundary. This is a side-effect of the
BEDO write caused by the BEDO write state machine flow. It does not affect
EDO writes because cta_dram_we_l has always asserted again before the
next assertion of cas_I.
Notice that the write cycle time is shorter than the read cycle time. The whole
sequence takes 281.25ns, which is identical to the BEDO write timing, bw_wcwr.

11-12 Simulation Waveforms

CPU_MCLK

ca·c'Tl
n;
........

CPU_HCLK_L
A
BYTES
0

BUF_A

l!lll"_J)
lO_D

HI 1M_A

l:e
~..,

W>M_ll

c1•11_M1tl·:v_1.
!Cf'U_!:1·:~1

Ci'IJ_Cl,F

C'l'/\._W/\l'l'_l,

t:l'll_l,fX'.K
Cl'll_\\'lll'J'I<:

M/\111_m·1

Ultl\M_I'.M

o•

•

lffHm1_~;1.1

IO_!;M
CTA_/\n~;c_1.

t.::'l'/\_mm_1.
1cT/\ CE l,

!cT/\=AD~_I,

1cTA_Ol!:_I,
DCU'r

l.JCIJT_CTI,
CT/\\CTl\\OO_DHAM

CTA \CT/\ \lll?AM_/\CK

: _f

CTA_llUFO_WROl::_I,

CTA_nuro_n1>0P._1.

(3)

CT/\_BUFD_RDG_f,

CTJ\_llUFO_WRO_L

!CTA_ltAS_L.

:J.

CT/\_C/\S_I,

CTA_r.m._cor.
MUX_h

tHH'i

l'.io~

~
iHi4

ooJ

~
on~·

C'l'/\_ORAM_WE_f,

CTIJ_Cl,KUY7

CTA_l>O_IO

c·rn_r.ATVJ_L

5·
:J

. . . er
..... :::s

CTB_IO_WROF._L

T (CPU_MCLK)

1
w

PAKA

:cTn_IO_RIXJB_I.

CTD_l.U-:l·IR_f,

......

3·

CTD_J.l\TU_L

m.
0

(2)

CTO_IO_/\CK

10. :lu

10.4u

Time (Seconds)

10.Su

:... :E
ed_wcwr

Cl> D>

IC. (ii

~ O'

""I (/)

Simulation Waveforms
11.8 ed_rdwrap

11.8 ed_rdwrap
This waveform, shown in Figure 11-8, was produced using the simulation script
'do_ed_rdwrap.cmd'.
This simulation shows a CPU cache block fill from EDO DRAM. This is an 8-beat
sequential read, like ss_rdwrap, and shows the sub-block wrapping performed by
the CPU.
The sequence shown in the waveform is similar to ed_wcrd, except that a longer
sequential access is performed.
This sequence takes 656.25ns (compared to 506.25ns for the BEDO).

11.9 bd_wcrd
This waveform., shown in Figure 11-9, was produced using the simulation script
'do_bd_wcrd.cmd'.
This simulation shows a BEDO DRAM worst-case read sequence. This performs
a 4-beat sequential read starting at address Ox0000.0008. Reads are performed
from addresses Ox0000.0008, OxOOOO.OOOc, Ox0000.0010 and Ox0000.0014. The
first two locations are in one BEDO burst block and the second two locations are
in the next BEDO burst block. Therefore, the DRAM state machine must cross a
BEDO DRAM block boundary during the access.
The waveform shows the sequence:
1. The sequence starts in the same way as an EDO DRAM read; up until the
assertion of cas_I, the sequences are identical. For the BEDO DRAM, the
first cas_l does not return read data; it only latches the column address. For
this 4-beat sequential read, there are 6 cas_l pulses.
2. The second assertion of cas_l returns the first beat of read data. The
column address is X (don't care) when cas asserts, since the read address is
determined by the internal burst counter.
3. The third assertion of cas_l returns the second beat of data. Once again, the
column address is X.
4. The burst counter reaches 0. This signals that, if another read were to be
done from the BEDO DRAM, the BEDO DRAM's burst address counter would
wrap (in this example, it would wrap to address Ox0000.0000).
5. Since this is not a wrapped access, it requires data from sequential addresses.
Therefore, a burst count of 0 causes the DRAM state machine to terminate
the current burst by toggling (asserting, in this case) cta_dram_we_l. Once
the burst has been terminated, the next cas_l will latch a new column
address.
6. The fourth assertion of cas_l latches a new coltimn address. Stall cycles are
introduced in the CPU cycle so that the address is stable for long enough to
meet the BEDO DRAM setup time.
7. The :fifth assertion of cas_l returns the third beat of data.
8. The six.th assertion of cas_l returns the final beat of data.

11-14 Simulation Waveforms

CPU_HCLK

CPU_HCLK_L

A
BYTES

ca·c'T1

~0000000\
0\11

7.ZZZZZZZ\

BUF_A

1)00001)(10\

IJlW_D

ZZZZ?,ZZZ\

10_1>

:t.7.'l.Z\11

IWM_/\

00000\H

IHJ!'1_1l

'/.Z.\11

c:::x

•.

Jl)

06000018

;t.;

I.I.

···

a . ·

;xx

··

00018

o . ,.

00000011

XXXXX:RX~

··

a . ·

(ii

zzzzzzzz

mJ · oOooOoOa - II)

o~c

_XI

·00000004

ooooc

(

00000

-z'!:"

,c.
C1>

a.
:e

1:p11_f.llH·:(l_f,

·l

Cl'l1_!>1·:1,.1

....
....

Cl'IJ_Cl,F

iil

t'.'l'l\_WAI'l'_I,

"ti

D
D

CJ>U_l.OCK
Cl'll_\\'lll'l'B
J.tl\lll_~:M

l>\11

l>ll/\M_~:H

02\11

HPHml_SM

0\11

lO_SM

0\11

' D
02

•

x::::==::!:•
00

.--0

'."E2
___

CTA_AllSC f,

C'rA_nw1.;_1,

CTA_Cl-!_J,

'1
L.

·•

CTA_l\DV_(,

CT/\_OP._(,
UCUT

l \II

llCllT_C'rf,

0\11

CTI\ \C'l'A \l>O_ORl\H

I~~

ct .-

::x:

-;o

2 •

c::::!

_J.l

CTI\ \CTI\\ DRAM_l\CK
CTA_DUf"O_WHOl·!_I,

c·rA_DUFO_ROOl.-:_I,
CTA_DUFO_HIX.:_f,
CTA_RllFO_WllG_[,

CTA_RAS_t,

C\11

CT/\_Cl\S_I,

1''\11

.:x

'C'rlt._Sl~L_CQJ,

HUX_/\

000\11

006

X!l . •

~
~

004

• LI

~OS

002

• ~

:x=l

000

::x

• ~

. ,.

C.:T/\_DR/\M_WIO:_f,

CTB_Cf,KDV7

(/)

~r
c:
:J

CTD_IO_ROOF._l.

CTA_IO_WHOE_l,

m.
0

~
~

.!,.
(JI

3·

;cTn_J,l\'rw_L

![
~

CTO_IO_ACK

c·rn_1,A'rn_1,

CT/\_DO_IO

PAK/\

a
c;·

0\11

..... :::J

.....

!C'l'l\_MF.MR_L

8.8u
T{CPU_HCLK)

e. 9u

9, lu

9. 60u

Time (Seconds)

9.2u

9.3u

ed_rdwrap

9.4u

U>~
lo. !a.
:e ~
C' <

c. (/)

.Ao
.Ao

.!.

(/)

3·

aer
:J

i
3

(/)

iCPU_MCLK

:!!

;cPU_MCLK_L

~I§·~~~~~~~~o~~~~~~~·rm:=:==:Il'.ll
:;:.:
:•
:
ca:n-;~~~~===~~m;~~;;;;;;~~~---~
=
~~~x~x~O:.~x~x~x~x~~~~~~:~~~~~~~~~0~·~~~~~~~;.~

00000008\

'A
D

.,,Z?.Z.7.7.?,Z\

BUF_A

00000000\

HIJP_I>

Z7.Z?.'l.?.?.Z\

10_0

Z;f.:-',Z.\11

IH!f.t_A

(J(J000\11

llOH_O

Z?.\11

00000010

00000000

x::;x

1:1'fJ_!:1·:0

c1>11_cr.1··
C'l'A Wl\l'I' I,
'
-

Lo:__

_._H

•

:: D

(
.: 06066014

..a.
..a.

OOOIT

cb
a.

l:e
.,
: D~--~------t
(')

r-:L-J

i_..

l:l'll_~·1Rl'l'E

l>\11

OJ:)

=ooooc-rx

Oli001i

H/~111_:;1.1

'"""Z"Z'rZ"',

Cl'IJ_MIH·:o_r.

c1•11_r.ocK

(;

·~~

Q\11

BYTES

Cl
~
1

•

·1

llHfll·l_!:H

02\11
0\11

Jo_::r·I

1)\11

or.

.oa

'1.

C1'/\_Al>nC_I,
CTA_U:t11·:_1,

:<:1'/\_CJ.:_I,

ier/\_ADV_t.
1C'l'A_Of-!_(,

BCllT_CTI,

1\11

0\11

IE§
·;

. :

14:,

'C1'A \CTI\ \OO_DRl\M

~::!::x:

ICTA_llUPl>_WROJ·:_r,

CTA_UIJPl>_Rlx;_t,
CTA_BUFO_\>JRG_J,
CTA_JU\S_L

C\11

P\11

;C'l'A_m·-:1._co1.

CTA_ORAH_Wl~_I,

00:\1·

CTD_Cf,KUY"I

:cT/\_OO_IO

:Tn_to_ACK

CTD L/\'l'W f,

!cTO=J./\TD=I.
l'Al<A

( 9 /.-

CTA_UUFD_RIX>..!_I,

iCTA_CAB_t,

CT/\ \C'l'A \ORl\l.f_ACK

I I

IF
•

L
l

(11

<2-i~.----, 3

r- ·- ·

i'.ilU~

( 6.)

(7)

(8)

X o ; X • 1 o 1 :• I
rnn

1-.f:(S)

o 1

Ol)S

....-

0\11

CTD_IO_IWOE_I,
C'PD_IO_\>moi.:_1.

c·rn_HEMn_r.
·1.4u
T(CPU_MCLK)

·1.su

#I. 6u

9. 6811

Tirre (Seconds)

-4

coc

C"-

a.a-·

n ::s

a.:e
I»

<B
.....
0

3""
(/)

JU--ltflll_m·I

.... CJ)_.

7. 7u

bd_wcrd

Simulation Waveforms
11.9 bd_wcrd
9. ras_l negates and the DRAM precharge starts.
This sequence takes 356.25ns.

11.10 bd_wcwr
This waveform, shown in Figure 11-10, was produced using the simulation script
'do_bd_wcwr.cmd'.
This simulation shows a BEDO DRAM page-mode write sequence. This performs
a 4-beat sequential write starting at address Ox0000.0008, and is the write
equivalent of bd_wcrd.
Although this waveform is identical to the waveform for the ed_wcwr sequence,
there are important differences in what is happening.
The waveform shows the sequence:
1. When cas_l asserts, the address for the burst access is latched into the BEDO
DRAM. The byte enables from the CPU (which have the same timing as
the address lines) are valid and meet the setup time into the DRAM state
machine logic. These byte enables determine which of cta_cas[3:0]_1 are
asserted. The first beat of write data from the CPU is latched into the BEDO
DRAM on this assertion of cas_l.

2. If the SA-110 has its write buffer enabled, random writes can merge in the
write buffer. Therefore, the first beat of this sequential cycle could have had
any combination of byte enables asserted (except none). For any byte lane
that has cas_l asserted, the internal burst counter will increment to the
next address in the block. However, for byte lanes that did not have cas_l
asserted, the address counter will not increment. This would lead to data
for subsequent beats being written to the wrong addresses. Therefore, the
burst is unconditionally aborted at this point, by negating cta_dram_we_l t.
An alternative would be to terminate the burst conditionally after any data
beat in which one or more byte enables were negated. In some systems, this
alternative would provide a performance advantage (by avoiding the stall
cycles that aborting the burst necessitates). In the EBSA-110, this alternative
method does not have any performance advantage because stalls must be
inserted in order to acquire the byte enable information, as will be described
below.
3. When cas_l asserts for the second time, the second beat of write data is
latched into the BEDO DRAM. However, in order to determine which cas_l
signals are to be asserted, the DRAM state machine requires the byte enables
from the CPU to be valid. The byte enables have the same timing as the
address, and 2 stall cycles are inserted so that the byte enables meet the
setup time into the DRAM state machine.

t As an example of what would happen if the burst was not aborted, consider this

sequence: Addresses OxO-Oxb contain 0. The CPU peform.s a sequential write which is
made up of a 32-bit store to address OxO (data Oxaaaa.aaaa), an 8-bit store to address
Ox3 (data Oxbb) and a 32-bit store to address Ox8 (data Oxcccc.cccc). The final contents
of the three longwords should be Oxaaaa.aaaa, OxOOOO.OObb, Oxcccc.cccc, but is actually
Oxaaaa.aaaa, Oxcccc.ccbb, OxOOOO.OOcc.
Simulation Waveforms 11-17

.....
.....

.!..

CPU_HCLK

CPU_l1CLK_L
A
BYTES
D

"!.ZZ'l."!.'lZZ\

§'

SUF_A

00000000\'

mw_P

?.?.?.?.Z?.:l.Z\i

1o_n

?,?,Z?,\11

IWM_A

00000\11

7.?.\11

IH>M_O

c1>11_r-m1-:t1_1.

::l

3
(/)

.~
:;::;r

~
~

0\11

(/)

[;#i

Cl'll_Cf,(·'

1:1'11_1,0CK

ll\11

nnMt_m-t
ltFlt:'>ll_!:l-1

(1\11

1o_m1

0\11

-:-

•.
11223~'4

::XX:0

0 00

c:v:

CCDDEEfP

c:l

Ooooc

06000610

:::=:x::=:v:

rn
a

x:xx:J

-----r--1

00014

LJ
-----o.

.!..
0

l:E

r-1
2

• .
n=
dOOOOOili•
: 00112233
c

001;1m3

CJ[

lq2)l4l

r-1
r-1
LJ
s:--L__t-

~
:::ex
00

1:1 111__ ~-m 1'fl·!

Ol\11

so99MDB

iHiooli

C1'1\_WAl'l'_f,

•
=x:n
; ~ ccit!""£
:x:J

·00

Il :

,t~l•IJ_f;I·:(~

1-fAill_!:l·I

lt
ca
c
(jJ
.....
.....

~=ex==-~,.;;;:;;,,~-==

')0000000\

-----

LJ
~

• "~

~
::x

--.-

CTA_/\ll!;(:_f,

cTA_u-..m_1.

C'l'A_cB_I,

C'l'A_ADV_I.

C'rti._(>r._r.
m:ll'r

nc11·r_cT1.

(4)

l\H

0\11

CTA \CTA \OO_DRAf.I

l~S§

E§:l
.

](

X I X

;

CTA \CTA \ORM·l_ACK

,CTA_UUPl>_WHOE_I,
CTA_HIJFO_ROOF._t,
I
;cTA_DUf'O_RIXJ_f,

11)

!cTA_DOPD_WRG_L
CTA_R/\S_L

C\11

CT/\_CA!.>_I,

F\11

CT5

( ~')

(6)

(5)

p:::x

x 0 x

'C'l'A_sm._co1.
MUX_A

000\11

CTA_DIU1.H_WB_I,

µ:

C'rll_CLKBY'/

i'.JiH5

:-,

na2

. l(2jl

n~l

• iH'i:5

nos

CTA_OO_IO
1cTB_IO_ACK
CTD_l.A1'W_L

l~:TB_l,A1'1LI•
PJ\KA

-.-

0\11

ICTB_IO_HDOl·!_L
'CTD_ JO_tomoF._L

,CTll_t1EMR_I,
7. 9u

T(CPU_l1CLK)

O. lu

9.68u

Timo (Seconds)

0.2u

bd_wcwr

~en

~-·

:-3
oc
tr!
a.-·

':e g
~~

"'I<

!!.
0
"'I

3(/)

Simulation Waveforms
11.10 bd_wcwr
Even if we had been able to use the internal burst counter address at this
point (by performing the optimization described above and not terminating
the burst) we still would have had to insert stalls; getting valid byte masks
requires as many stalls as getting a valid address would
The disappointing end result is that writes proceed at the same rate as they
do for EDO DRAM writes.
4. The burst counter reaches 0. If the burst was being terminated conditionally
(which is not the case in the EBSA-110 design) the fact that the burst counter
had reached 0 would be another factor that must cause the current burst
to be aborted. In the EBSA-110 design, the state of the burst counter is
irrelevant during these writes.
5. The third assertion of eas_l latches the third beat of write data, with its
address.
6. The fourth assertion of eas_l latches the final beat of write data, with its
address.
The end result is that writes cannot take advantage of the increased performance
offered by BEDO DRAMs. The exception to this is the cache block evict sequence,
shown in Section 11.12.
This sequence takes 281.25ns.

11.11 bd_rdwrap
This waveform, shown in Figure 11-11, was produced using the simulation script
'do_bd_rdwrap.cmd'.
This simulation is a CPU cache block fill from BEDO DRAM. It is an 8-beat
sequential read that shows the sub-block wrapping performed by the CPU.
The waveform shows the sequence:
1. Since epu_elf is asserted, bent is loaded with 3, regardless of the value of
the address bus. This ensures that 4 data beats will be read, wrapping within
the BEDO DRAM block if necessary.
2. The first assertion of eas_l latches the address for the burst read. The next
four assertions of eas_l read four data beats.
3. The bent value reaches 0. Since this is a wrapped read, this indicates that
4 data beats have occurred rather than indicating that the burst address
counter has wrapped. The result is the same, though; the DRAM state
machine toggles eta_dram_we_l to terminate the burst.
A BEDO read cycle that crosses from one block to another must always
terminate the first block read with a burst abort sequence. The BEDO
DRAMs allow a new address (for the next block) to be latched into the DRAM
on the fifth cas_I (the eas_l that reads the fourth data beat from the DRAM).
In other words, it will latch the address for read data 5 at the same time as it
provides read data 4. However, the SA-110 will not generate the address for
read data 5 until it has received read data 4. Therefore, the EBSA-110 cannot
take advantage of this pipelining facility.
4. The fifth assertion of eas_l latches a new address. The next four assertions of
eas_l read four more data beats.

Simulation Waveforms 11-19

....
....

it,
0

lCPU_MCl,K

lCPU_MCLK_L
A
BYTES

~0000000\
0\11

3·

ZZZ7.ZZZZ\I

BUF_A

00000000\

er
5·

nu1··_0

7.7.7.7.7.7.7.7.\

10_1>

f.Z?.1.\11

(/)

::I

m.
0

lmH_A

000(10\11

noH_I>

7.Z\11

mx:

o·:

FrF

t:l•IJ_l:J,p

...
0

::;x
~·

-nr

00018

:x:x

IJ\11

llHAH_ml

(1~\11

lcl"Hml_!:M

0\11

1o_mt

0\11

.
:

l!X , F cr=:Y7X:I

[ll

a:J~

.Lt;

i8.

-n-

CiJ

::nn:::::::::::

c...x:::x:

n
·
n:O:

n ·

. ..,,..

•

.
l.

C1'A_Arn;r:_J,

c1'A_nwi-:_1.

iCTA_CP. f,
:CTA_AUV_I,

.,..

!cTA_OH_I.
HCUT

1\11

llCtl'f'_CTl1

0\11

C1'A \C'rA \ l.>O_l>JIAH

ICTA\C'rA\f>RAH_ACK

TA_DUFO_Rl>OB_f,

;CTA_DUP1>_HIX;_1,
I
ICTA_RUl"l>_WHG_I.

0
0

CTA_RAS_I,

C\11
.~,

cTA_sm._co1.

!HUX_A

000\ll

'icTA_onAM_wi:-:_L
CTD_Cl,KUY7

CT/\_00_10

!cTU_IO_ACK

iCTB_LATW_L

;CTIJ_LATO_f,

PAKA

..,,...

-r.rx- ~b:x

x
t

:::x==!

..,,..

:x
::!JC!!](

~·

,..

"'T

....f
_f

<:il:
J

-r-.:!

'""(_

!cTA_CAS_I,

-r.-r -r-.-Y

l~TA_UUPl>_WROB_I,

.,..

(3)

·lC'"

~ria~;r

IHI 001 :1

'Olll"

::r:~

,1-J

"'W"::c:x--09,....1~x:
l___f

-f

..r

(4)

..,,...

0\11

'CTll_IO_ROOF._f,

CTU_IO_WROB_L
CTD_HHHR_J,

6.8u
T(CPU_MCLK)

6.9u

7.tu

9.68u

Time (Seconds)

7.2u

'/,Ju

bd_rdwrap

era

,a.

~~
m<

-4 - ·
:....
3
-4 c

I., 0

iiiJ

o·n:n

-4 CJ)

.....
.....
1
.....
O"

t:1•u_wn I'l'B

HAlll_!:H

~·

= : · m·
=-==-::

cpu_m·:(,,J

ICl•U_l,fK:K

:r:r

ICl'U_l·tHl·:(:J_I.

C'l'/\_t-.'A l'l'_I,

::!!
ca
c

D.-.
Q.

..a'

"C CD

3tn

Simulation Waveforms
11.11 bd_rdwrap
This sequence takes 506.25ns.

11.12 bd_wrf
This waveform, shown in Figure 11-12, was produced using the simulation script
'do_dram6.cmd'.
This simulation shows a BEDO DRAM full write. This is a 5-beat t sequential
write corresponding to a cache block castout or the write of a complete write
buffer entry. For these cycles, the CPU asserts cpu_clf as a 'hint' that the
external circuitry need not monitor the byte enable signals. This allows the
DRAM state machine to assert all cta_cas[3:0]_1 signals during all beats of
the write, and therefore overcome the performance limitation described in
Section 11.10.
CPU full write sequences have the additional characteristic that they always
start on INT16 address boundaries.
The waveform shows the sequence:
1. The first cas_I assertion latches the column address and first beat of write
data, as before. The three subsequent cas_l pulses latch the remaining data
for the BEDO DRAM block.
2. The burst counter reaches 0. The DRAM state machine aborts the current
burst+ by toggling cta_dram_we_l.
3. An additional stall cycle is introduced so that the CPU address (for the start
of the new burst) will be valid at the BEDO DRAM.
4. The :fifth cas_l assertion latches the column address and :final beat of write
data.
This sequence takes 281.25ns (a 5-beat non-elf sequence takes 318.75ns).

11.13 rfrsh
This waveform, shown in Figure 11-13, was produced using the simulation script
'do_rfrsh.cmd'.
This simulation shows a DRAM (EDO or BEDO) refresh sequence, sandwiched
between two DRAM reads.
The waveform shows the sequence:
1. A non-sequential DRAM read starts. The DRAM state machine is idle, and
so do_dram (asserted by the Main state machine) causes the DRAM state
machine to transition out of its idle state and start a read access.

In practice, CPU full write sequences will always be either 4 beats or 8 beats in length.
This example is contrived so that the whole waveform can fit on the page and remain
readable .
.,. Since the burst was aligned, it is not necessary to abort the burst at this point; the
next cas_l would automatically latch the column address. However, the abort incurs no
performance penalty in this design, and is a side-effect of the non-elf write sequence in
the DRAM state machine.

Simulation Waveforms 11-21

........
~
(/)

3·
c

f
~

'CPU_MCLK
:CPU_MCLK_L

"Tl
ca·
c

~0000000\

.......

~~~~~~~~~~~~~~~~~~~~~~~~~--,.

BYTES

0\11

Z7.7.7.ZZ7.7.\I

!BUF_A

00000001t\I

OIW_U

ZZZZZ?.ZZ\

10_1>

7.?.7.Z\11

IUlH_A

(1(1000\11

HOH_I>

Z?.\11

::n::o:

::n::

-r=r

m:::x:x:_

:x:;:_

:x:::I

!!!!:r::«

-r

.-r-r

~·

::I

........

I.l

an __,,.JJ"3"'3""JJ"3"'3-L::J:
n:x:x

!!!XIII

CiJ

::J:

,o.

o~=============~
-c:::r
-c:::r
-r:;:::r
u:::r
t::J C:~I
~

c~J>tl_MHHO._I.

't:l'IJ ::1·:v

lcl'IJ=<'l,I·~

IC'l'A_t·JJ\l'l'_I,

Lc:i

CPIJ_(,OCK

rc:I

lt:l'IJ_WHl'l'I•:

MAlll_nl-1

U\11

IUCAl-t_::M

()2\11

ltPUml_t:M

0\11

Jo_:m

0\11

___c]_

~
00

-c:::r

•__ X"

___c]_

-c:::r

,II"

!
:x

Cil!"

""11'

C'rA_A1>rn~_1.

'l.

C'rA_HWB_I.

C'rA_CE_I..
C'l'A_ADV_f_,

1·

E§

:::: I

I .

1C'l'J\_<JB_I,
HCllT

ncrl'r_cTr.

1\11
0\11

::TA\CTA\OO_l>RAM

(2)

3
0

CTJ\\CTA\ORAM_ACK
ICTA_DUFD_WROB_L
ICTA_DUPO_RllOICL

CTA_RUFO_Rl>G_I,
I
CTA_RUPD_WRO_f,
:CTA_RAS_L

ICTA_CAs_r.
CTA_mu._co1.
HUX_A

000\11

111

~x u I

~o!!:JJ!!!:J

nan

• I ~u Q:::::X

iCTA_llRhH_WE_I,
ICT8_CLKDY7

::TA_OO_IO

iCTB_IO_ACK

Tll_l,J\TW_I,

IC:TU_t.lt.'l'O_I.

PAKA

l
0\11

[CTO_IO_RIX>B.... L

o~•1°X
002

:1xxx~

.--:-1

llH:

l
~

---.

ICTB_IO_WROE_f,

lcTD_MEMR.... I,

8.4u

TICPU_MCLKI

8.Su

9.68u

Time {Seconds)

::J" :S·

!.
0
"'I

t::J

~~ ~

--·
WC
=lf!I,
...00-·
;:<
:....3

3
fn

...r::::I.

t::::l"

•en

8.6u

bd_wrf

CPU_MCLK
icPU_MCl.K_L
IA
BYTES

ll!X

=x:

D
BUF_A

xxxxxxxx :

(llJ

Cil

zzzz~zzz

.....
.....

x~xxxxxx

:.nx

lllil

l!
ca
c

ommoooc

zz.zzzzzz

HIJP_I>

1n_n
l<OM_A

----;oooou
-.--

UOM_I>

c110_1-11mv_1.

e1•u_::1·:Q
l
Cl'll CM·'

lc·rA=~·1A 11'_1.
c1•11_1.ncK
Cl 1 lJ_~~HI'fl-!

H/\lll_m.t
111tA.f1_!;f.I

1u:ma1_m1

~·
:
:
G;?
to:

: ~

·"

;ooooc
-.--

iil

(3)

[-;;

;

,...

::LI:

::::r

'---~~~~~~~~~~~~~~~~~~~~~~~~

D
0

lC:r=]
0
~"l·l4~0•1•ox•~1•2J<:!!
~
l
\51
·~
!Bl
!YI •o

ICTA=UWB_;.

1c·rA_cr·:_1,
iCTA_l\OV_L

iCTl\_011,_l,

l.
.-

---

HCll'I'

ncn·r_C'rl.

: 0

jC'l'A \CTI\\ OO_DRl\H

.l.

J.l

CTA_DUFD_wnmcr.
;CTA_DUPD_ROOB_I,

_J.

CTA_DUl"D_ROO_l,

_r----;l__
I'

CTA_CAS_L

;11ux...J\
lcTB_ct.KDY'l

3·
c:

~
0

~
!!l
0

~
.....
.....

c·rA_OO_IO

.•

_J
_J
_J

(7)

!cT/\_UUFD_WRG_I,

ICTA_OR/\l{_WE_l,

::x:

le TA \CT/\\ ORAM_ACK

jC'rA_sm._co1.

=x
p
~··~

1o_m1
c·rA Alme 1.

1CT/\_RAS_I,

(10)

:x::::x

llili

x·

I .~

c:JX .

. I

(6)~ i

lil'ilJ

x·

(

t:x:

n1n

:::l 0
'

: ~n

[
;v

.: L:

_i:

1-+f

CJ)

3·

iCTll_IO_ACK

!CTD_l,A.'rw_r.

a
c;·

CTD_l.ATR_l1

PAK/\

CTD_IO_ROOF.._f,

ICTO_IO_WROILI•

::s

!cTD_HEMH_L
10. 7u

to.Ou

10.9u

tlu

11. lu

rfrsh

T(CPU_MCLK)

Time

(Seconds)

:;:
. <
..a. CD
w_
::s. 0

. ..
a> 3

:::r a>

Simulation Waveforms
11.13 rfrsh
2. Simultaneously with the DRAM read sequence starting, the refresh counter
times out and the REFRESH state machine generates a refresh request by
transitioning out of its reset state. A refresh cannot start yet, because the
DRAM state machine has committed to the read cycle.
3. A second non-sequential DRAM read starts.
4. do_dram asserts for the second read.
5. The DRAM state machine completes the RAS precharge for the first read and
passes through its idle state. At this point, it samples both do_rfrsh and
do_dram asserted. A refresh request always has a higher priority than a
CPU cycle, and so the CPU continues to be stalled.
6. cas_l asserts with ras_l negated. This is the start of a CAS-before-RAS
refresh cycle.
7. ras_l asserts, for the CAS-before-RAS refresh cycle.
8. The DRAM state machine goes back to idle as the result of a rfrsh_ack (not
shown on these waveforms).
9. The refresh (and the RAS precharge) completes, and the DRAM state machine
goes back to its idle state. At this point it samples do_dram. asserted (do_
rfrsh is now negated) and starts a DRAM read cycle.
1 n Tho .,..,,.,.,:i P171'lo l'nTnnloto" ,..,..,:i tho f"!'PTT ,...,,.1.,,. ;., t......,.,.,1nato..:I
--·

- - - - - - - - -.1 - -

---r----- -- -- -- - -.,-- -- -------·

Note that a sequential read cycle will not be interrupted by a refresh; the DRAM
state machine will complete the whole cycle. The refresh request occurs just after
the first DRAM read has started but it is held off until the read has completed.
Once the RAS precharge has been met, the (CAS-before-RAS) refresh sequence
starts. At the same time, a further CPU read starts but is held off by the refresh
in progress. Once the refresh has completed and the RAS precharge has been
met, the CPU access proceeds.

11.14 cbr
This waveform, shown in Figure 11-14, was produced using the simulation script
'do_cbr.cmd'.
This simulation shows a CPU-initiated write-CAS-before-RAS (WCBR) cycle
followed by a CPU-initiated CAS-before-RAS (CBR) cycle. These cycles are used
to configure the BEDO DRAMs.
CBR and WCBR cycles are generated by CPU write and reads to the DRAM
address space when the SOFT_DCBR bit is asserted.
The waveform shows:
1. A non-sequential write to address OxXXXX.XX80 starts. (The upper-case X
indicates that the address line has been set to the 'unknown' state. What you
cannot see on the waveform t is that the two high-order address lines are set
to select the DRAM space, and that some other high-order lines select which
DRAM bank is decoded.)

t The waveform shows the value of each nibble. If any bit in the nibble is X, the whole
nibble is shown as X.

11-24 Simulation Waveforms

CPU_HC(,K

A
BYTES
D
BUF_/\
llllF_I>

.
x::::=:--x

Jo_n

UOl-1_/\

XXXBQ

IWH_I)
<'l'll_f.lHl•:(.l_l,
Cl'll __ !:E<,.1

Cl'IJ_Cl,I·'

Cl'll_l,llC}{

t:l'IJ_HHITI·:
1-l/\Ill_~:M

J:::::l

;_r

1'1

:x xxxxxxxx : x:

zzzzziiz

zzzzzzzz .

(jJ

....
....

.!,.

.i::.

xxxao

..,g.

:
1-

___o_
--,,-

::x=:::!:
00

1))1/\M_:;M

C'l'/\_W/\l'l' !,

xzzzz
-:r:x
--n-

. xxxxxxxx

XXXXXX80

ca·c'11

~ ~ ~

l(l··n:>il_SH

10_!;1·1

~ -~

C'i'J\ \C'l'A \Pit I Ml·:_MJ\P
C'PJ\ \CTI\ \llORMl\l._M/\I'

c·r/l._/\n!;c_r.

CT/\_Bl\'E_I,

l___J

CT/\_cg_f,
f'.TA_Al>V_l,

C'P/\_01-!_I,

IJCUT

.
~·~~::::==~C=i~~i~I

BCtlT_C'ff,

CT/\ \CT/\\ OO_DHAH

CT/\\C'l'A\Dlt/\H_/\CK

(5i---i

C'l'/\_lllJFD_WROE_J,

CTA_l3Ul•'ll_nt>Ol·:_I,

·2

CTA_nur~n_ROO_I.

...,,
x

CTA_BUPD_HRG_L
CT/\_RJ\S_L

CT/\_Cl\8_f,

;:::x:

cTA_m-:1._cor.

MUX_A

...,,

xxx

JC
L_

xxx

CTA_ORAH_Wt-:_f,

CJ)

3·
c:

e6"

PAI</\

r
it,

as·

C'J'B_f,/\'fW_I.

c-rn_1Nro_r.
CTB_IO_HOOl·:_l,

-lo
-lo

3·

c":'flJ_IO_/\CK

C'l'B_cl,J<BY7
CTl\_00_10

::s

~CTB_IO_WROF._l,

24u

24. lu

24 ,2u

T (CPU_HCLK}

Time (Seconds)

24, 3u

cbr

/usr /usct·s/crook/vl_.<1xp/cllr;a l l0/ l·cv2 /~

-....
=--- Ci

~o
(')

CT (/)
3

Simulation Waveforms
11.14 cbr
2. do_dram. asserts, taking the DRAM state machine out of its idle state. The
DRAM state machine starts the state sequence OxlO, Oxll, which is the
refresh sequence (refer to earlier timing diagrams to see that normal read
and writes to DRAM cause a different state sequence).
3. cta_cas_I asserts (all the cas_I signals assert: the bus of four signals
changes from Oxf to OxO) whilst cta_ras_I is still negated. The mux_a value
is 'unknown'.
4. One clock later, cta_ras_I asserts (some combination of ras_I signals assert,
depending upon the address decode and the size of DRAM SIMMs fitted).
The mux_a value is OxX20. This value is a transformation of the address
OxXXXX.XXBO on the address bus.
BEDO DRAMs latch configuration information on this falling edge of ras_I.
The configuration information is latched from the low 8 bits of the address
bus. The value Ox20 configures the DRAMs to operate with a linear (rather
than interleaved) burst sequence.
5. Finally, the DRAM state machine asserts dram_ack, the Main state machine
terminates the CPU cycle (by negating cta_wait_I) and the DRAMs perform
their precharge sequence.
6. A non-sequential read from address Ox:XXXX.XXBO starts. In this case, the

address is only used to select the DRAM space, and the particular DRAM
bank. This cycle is the same as the write cycle, except that cta_dram_we_l
is negated when ras_I asserts.

11.15 romrd1
This waveform., shown in Figure 11-15, was produced using the simulation script
'do_:flashrd4.cmd'.
This simulation shows a 1-beat (non-sequential) read from EPROM. Since the
EPROM is an 8-bit device, four 8-bit values are packed to supply a 32-bit value to
the CPU. The two low-order address lines to the EPROM are supplied by a 2-bit
counter, pak_a.
The waveform. shows the sequence:
1. The CPU starts a read cycle from the EPROM.

2. This causes do_io to assert; the IO state machine moves out of its idle state.
3. The low-order EPROM address lines are provided by the paka counter. This
is reset to 0 at the start of the cycle, and counts through to 3 during the cycle.
4. When the read access time of the EPROM has been satisfied, the first byte
of data from the EPROM is latched in the ROM data buffer by negating
ctb_latb_I (latch byte).
5. The read data propagates through to the CPU data bus, but the CPU cycle
remains stalled. The CPU data bus shows the value Ox0000.0000.
6. The EPROM address is incremented to Ox0000.0001. The second EPROM

read commences.

11-26 Simulation Waveforms

l~Pll_HCLK

ca·c'11
;
........

BYTES

BllF_A

1uw_u

....I

10_()

(JI

HOM_A

noz.t_Jl

!t:PIJ_MllB(1_(,

l~l'lf_<:l.I·'

a
....

:1:'1'/\_WA l'r _1,

:c1•u_WHl'l'B

;M/\lll_m-1
l>HAr·l_!;M

62,

·~

iJ~

)C)GX

~·

OA,

Ill!'"

IU'IU:ll_t:f.t

~·

JO_!;M

CTA \C'rlt. \DO_URAf.I

CTA \C'fA \DHAH_ACK

c•r.a._nmm_wno1-:_1.
lC'l'A_RUl.'O_RIXlF._J,
CTA_HtJFD_RIX1_1,
CTA_IJUPO_WRG_L
CTA_RAG_I,

ICTA_CAH_I,

!cTA_sm._cot.
HUX_A

iC'l'A_A()~;c_l,

fi1i

:
00(

,li:i

iJ~

~
~

•

t.---i_

; r.-----i:.

~ f;--i

' :

::::xx

ICTA_ORAM_WE_L

ICTll_Cl.KDY'I
CTA_DO IO

ICTH_IO_ACK
CTU_l.ATW_I,
'
,CTD_LATU_L

·I

: I

L..;___J.

L._;__J .

L____;J

: I

W121

~(3)

PAKA

iCTD_IO_ROOF._J,
CTB_IO_WROP.._I,
I
CTB_MEHR_I,

(4)1

p(7) !

~ 2

(9~. x

l ~ l
I

CTU_HEl.tW_L

!!-!
3c

~
0
:J

3·
c

1cTD_Pl.ASll_WR_t,

a
c;·

!cTO\C'J'O\TRJCK_WR

:aov
7.WS_L

m.~

:TIHBR

~
....
....
~

IT (CPUJICLKI

CTO_IOR_I•

jc1·u_1ow_r.

lcTH\CTll\Cl,R_TJMHH

"'
lt.2u

11.Ju

11.4u

'
11.Su

11.6u

Time (Seconds)

'
11. •1t1

It.Ou

11 ' 90

romrdl

12u

/usr- /uae1.·a/e1·nok/vl _1txp/ ebaa l lOt 1·av2 /apa

..... :s
.....
:..,.~
Cll<

a
a
30
., .,
a. 3

..a. UI

Simulation Waveforms
11.15 romrd1
7. When the read access time of the EPROM has been satisfied, the :first and
second bytes of data are latched in the IO_D data buffer by the negation of
ctb_latw_l (latch word). The first byte of data is provided (on io_d[7:0]) by
the latch in the ROM_D data buffer, the second byte is flow-through (onto
io_d[15:8]) through the ROM data buffer.
At this point, the CPU data bus shows the value OxOlOl.0100.
The waveform shows the progress of read data from rom_d to io_d to buf_d
and :finally to d, the CPU data bus.
8. The EPROM address is incremented to Ox0000.0002. The third EPROM read
commences.
9. When the read access time of the EPROM has been satisfied, the third byte of
data from the EPROM is latched in the ROM data buffer in the same way as
the :first byte was; by the negation of ctb_latb_l.
10. The EPROM address is incremented to Ox0000.0003. The fourth and :final
EPROM read commences.
When the read access time of the EPROM has been satisfied, all 32 bits
of data are available on the CPU data bus. The IO state machine asserts
ctb_io_ack to show that its cycle has completed, and the Main state machine
negates cta_wait_l to terminate the cycle.

--· cpu_mreq_l
.. -- --·- -·------ ---- --r--- ------ ------, -· -------- -is negated, and so it negates cta_do_io to indicate that no

~OT\

tho 'J\A'Q;T\ cri-QtO T\"1Qt'h;1'\A C!Qn>T\lAC! fn

gp'lz-

QC!C!OriON ;+ NOto'f"Tn;T\O!:! tnQt

further data beats are required.
When the 32 bits of data are driven on the CPU d bus, the four bytes are
sourced like this:
•

Bits d[31:16] are driven from the latch in the IO_D data buffer, and :fiow
through the BUF_D data buffer.

•

Bits d[15:8] are driven from the latch in the ROM_D data buffer, and
flow-through the low half of the IO_D data buffer and the BUF_D data
buffer.

•

Bits d[7:0] are driven from the EPROM and flow-through the ROM_D
data buffer, the IO_D data buffer and the BUF_D data buffer.

11.16 romrd2
This waveform, shown in Figure 11-16, was produced using the simulation script
'do_flashrd4.cmd'.
This simulation shows a 2-beat sequential read from EPROM. It shows how the
IO state machine handshakes with the Main state machine.
The waveform shows the sequence:
1. The read cycle starts.
2. The Main state machine asserts cta_do_io and the IO state machine
performs a packing sequence as before.
3. The IO state machine asserts ctb_io_ack for one clock cycle.

11-28 Simulation Waveforms

;cPU_HCLK

"JX.
Dx:

A
BYTES

::=):)(

~--x

::x:
::x:

J:j,,

IH1H_A

WJM_D
l'.1'11_1.mE(,1_1.

Cl'IJ __<~l.F

OQOOO

h:
n·. <1>
"

,00001

,00002

Jx::=::;:: 00004

, 00003

- .

n <4i.

::X , 06o6050j

·~

~
~

~ ~
00006 •
l(
.J(---; ··-0.-

"""1mi4

0101

:::!:

il.OOOOW4

004

Jl!IF_ll

JO_!>

~·

BUF_A

~
°' ···~

0000·1.

ca·"T1c
iiJ

......

.!,.

0
3

C1'/\_W1\ l 'l'_J,

I\)

{'.l'U_Wl~l'l'E

o.J\."---~--~---~--~---~--~---~--~......;._
'1)0

M/\ 111.-~:1·1

lllU\M_!:f·I

::!:

lu.'U!:ll_l:t·I
00

I11_!;f·I

Of\

02 ,

0/\

O.,

02,

07,

Oh.

DA.•

O).

DA,

C:'J'/\_ /\D~;c 1,

C'l'A \C'l'A \ ll<l_DHAf.I

C'l'A\C'l'/\\DIUIH_AcK
C1'/\_Bl1FD_WllfH-:_(,

CT/\_UllFll_l<O<Jt·:_f,
CT/\_IJUl~O_HOO_(,

C1'/\._llUFl>_WIW_I,
CT/\_HAS_I,

CTA_CA!;_(,

~§ : : : : : : : i......R i :

C1'A_sm._cob
MUX_/\

. xx .

•lilil5

'CTB_cl.l<OY7

(2)

•

(3)

•

CTfi_lO_l\CK
C'.l'B_f,l\TW_I,

c·rn_r.ATB_I.

~- ;_1.

PAK/\

CTO_IO_IH>0£_1,

1:-t

_J
0-.

--.

;::x:

.-,_

. ,-.-

:_r

..,

:x:

,§

006

C1'A_IJR/\H_Wl-:_1,

iC'l'/\_IXl_IO

-,_

: _f

(5T

~
x

K!l

CTD 10 WROE 11

lcTa=r.u·:~R_t. C'l'ILMEMW_f,

CTR_IOR_f,

C'rfl\C1'H\ 1'R ICK_WR

~r
c:

er::J

~!R.

......
.t,
co

CJ)

3·

CTU_IOW_L

CTR_Pl./\f:ll_Wl~_I,

ROY

7.\'m_1.

·rrnrm
,C'l'll\CTB\Cl,H_TIMfm

·:

.....
: I
17..Su

: n:
Du

T(CPU_HCLK)

Time (Seconds)

: n:

:
13. Su

f'4

romrd2

/11s1· /uset·s/crook/vl_.axp/ebsa l 10/rcv2 /upc

..... :::s

~:e

a> D>

.., <

!1
30
.., ..,

c. 3

N (I)

Simulation Waveforms
11.16 romrd2
4. The Main state machine responds by negating cta_wait_l for one cycle so
that the CPU can sample the read data. However, cpu_mreq_I remains
asserted (indicating that further data beats are required) and so the Main
state machine keeps cta_do_io asserted.
5. The EPROM address counter wraps around to 0 and a new packing sequence
begins.
6. The packing sequence completes and the IO state machine asserts ctb_io_

ack for one cycle.
7. The Main state machine responds by negating eta_wait_l, as before. Since
cpu_mreq_l has now negated, cta_do_io is now negated.
8. The cycle has completed so the IO state machine goes back to its idle state.

11.17 flashwr
This waveform, shown in Figure 11-17, was produced using the simulation script
'do_:fiashwrl.cmd'.
This simulation shows write accesses to 5 sequential addresses in Flash. These
must be performed as separate, non-sequential writes.
The waveform shows the sequence:
1. The :first write access is to address OxS000.0000. The Flash address bus
(shown as rom_a) is showing address Ox0000.0000. The two low-order
address lines are supplied by paka[l:O].
2. The Flash write cycle is performed by the IO state machine, and the actual
write is performed by the assertion of ctb_:ftash_wr_l.

During Flash writes, data is always provided on the low-order byte lane.
3. The second write access is to address Ox8040.0000. High-order address lines
(buf_a[23:22] are used to jam-load the paka counter. The Flash address bus

drives the value Ox0000.0001.
4. Subsequent write accesses are to addresses OxSOS0.0000, OxSOC0.0000 and
OxSOC0.0004. The values on rom_a shows that the control logic converts
these into an incrementing set of addresses.

11.18 io
This waveform, shown in Figure 11-18, was produced using the simulation script
'do_io.cmd'.
This simulation shows a read-write-read sequence to ISAIO space. Each of the
three cycles is a non-sequential access, but the cycles are performed back-to-back.
This allows the data bus turn-on/tum-off times to be seen, showing that there is
no tristate overlap on the data buses.
The waveform shows the sequence:
1. The CPU starts a read cycle, and is stalled by the Main state machine.

11-30 Simulation Waveforms

iCPUJ!CLK

:A
BYTES

ca·c"Tl

0400000\
l\lt

;
.....

Z'ZZZ:ZZZ.Z\

BUF_A

~XXXXXXX\

mw_o

?.ZZZZZZZ\

JO_I>

Z?.Z:Z\11

ROI-LA

XXXXX\11

ROM_U

?.Z\11

......
......
I

Cl•tJ_Hltt-:Q_I,

I»
fl)

r1•u_r.1.1-·

:::r

C'l'/\_WAl'l'_I,

:t;Pll_Wlll'l'I-!

!HAllJ_m.J

0\11

l>llAM_m·I

00\11

Hl"Hmr_m..

CJ\11

l<.t_:;H

00\11

C'l'/\_A1>~;c_1,

C1'A\C1'A\1>0 DRAM

ICTA\<!'fA\UH/\1-l_ACK
C1'A_RUFD_wnoE_I.

IC'rA_DUPD_IUXJR_r.

CTA_SHL_cor.
J4UX_A

i---i:

rlh

• r--i:

IC'l'A_RUPD_WllG_f,
C'fA RAS L

!cTA=CAS=f,

I'.
!

CTA_HUFO_Rtx:_f,

I mt

F\11

P\11
0

XXX\11

:II
11

"1llO

1oooxx •

JIX.

icTA_l>RAH__WE_f,

1cTn_c1.Knv·1
CTA_DO IO

·:X:

-;r

lcTn_tO=ACK
CTD_LATW_J,

ICTU_t.ATD_t,

PAKA

(

--.-

0\11

CTD_IO_RDOE_t,

i--h.

lcTD_IO_WROR_I,

.--.-

::JC.!X:

.-,-

·:X:

.
.-.-

_rr:,_

CTl1_HRMR_L
CTB_HEMW_f,

(J)

3·
c:

aa·

CTD_IOR_l,
CTD_IOW_I,

CTD\CTD\TRICK_WR

zws_1.

TIMER

~
....
....
~

a·:::J

2\1!

cTD\CTD\CLR_TtHFm

l4U

iT(CPU_HCLK)

3·

ROY

:::J

;cTD_FLASll_WR_l.

14 .Su

lSu

14 .3735u

Time (Seconds)

15. Su

flashwr

16ll

/uai- /uae_ra/!O'rook/vl_axp/cbsa 110/ 1·ev2 /spe

~Ci

.....
..a.0
CX> .,

0-·3
(I)

........

l~PU_HCLK
BYTES

lauF_A

erg'

ROl.f_I\

::XX ·
~

en
~·

JDULl1JUUUUUULl~.n.n1Ln~

•

:
:
x::x===x

"::Jtl. :

J..

HlJP_U

IO_O

1un-1_n

1cp11_r-mm.LI•
Cl•IJ Cl,I'
IC'l'A=WAl'l'_J,

::xx '

.zz

Pxxxxxxe

_JI..

mtAt-L:m
Jo_nM
IC'l'A Alme 1.

1C'J'A\CTl\\Drt_l>HAl-I

IC'l'I\ \C'l'I\ \IJICAH_ACK
:CTA_IUJl'D_wnm.:_r.
!

t:'l'A_UUFl>_RIX°Jl-!_I,
lIC1'1\_UUPU_IU>G_I.

'ic1·A_1mP1>_wuc..:_1.
C'l'A_HAS_l1

~ J...

·a
~~

:!:Jd

1--l:

XX7{A

-2.:

JU(; ~

XX •

(«:)(lO(

zzzz :

•

xx:

xxxxc.

~i., ~

1w1w11_::1-1

• 5fxii5fft:5f
FXXXXX$

lt~l•IJ_Wl<l'l'f.:
HAlll_::M

•

•:

.A' ..a

xx.

~"'

6
•

JOl
JOl

•

..!.

~~XJIXC

.....

:X·

:x: :x

JM.
.l..

....
J..

:xx
'

•

:x
•

·:x

_JI..

•

J...

::x:

·~

_!!_

J.I
x ._._

..£

::<"!:
__'!.;_

x ....... xx "" xx ::!!!::X: ...!!:

r.J( :ir.r·

ICTA_CAS_I.

F=R

JJ... ~ _x, ~ Jl

• ~ J...J... .~

•

• •

lcTA_sEr,__cor.
'MUX_A

0)(

TA_ORAH_WE_J,

TD_c1.Knv·1

TA_OO_IO
1'U_IO_ACJ<

TD_l,l\TW_L

-====~~--===:::::.~
'

cn>r

!L__

C'rO_t.ATD_I,

l'AKA
'TU_IO_UOOB_L

CTD_IO_WROP._I,

iTITY

(11):

:r-

CTD_HEHR_I.
TD_HEHW_L

CTD_IOR_J,

ll--'-:----ii (61

;

..---i

~ t (121

CTD_IOW_J,
CTD_fo'l.J\6H_WR_I,

CTD\CTH\TRICK_Wll
ROY
?.WS_J,

l'rIHER
C1"D\CTD\Cl,R_TIMP.ll

<:il

;

: can

n :

16.su

----r.--i
.
l7u

'T(CPU_HCLKl

Time (Seconds)

n:.

io
/U•rluaera/erook/vl_~ebaa110/irov2/ape

-4(/)
-4 - ·

iii

00 c

1
00

:::s

........

a·

(15)

..r:1
:!::

:x:
:

x ~ :xx ~ xx ""·:X:
LI

c:ra

~
<

.,a3(I)

Simulation Waveforms
11.18 io
2. The Main state machine decodes an I/O access and asserts cta_do_io to the
IO state machine.
3. The IO state machine moves out of its idle state to start the read cycle.
4. A 2-bit timer (timer) is used as a resource by several state sequences within
the IO state machine. This avoids adding a large number of states to the
state machine (which would have the effect of increasing dependencies in the
next-state and output-decode logic).
5. The IO state machine can detect the count value of the timer. The timer will
wrap around from 3 to 0, or can be explicitly reset by the IO state machine
using clr_timer.
6. After a delay (imposed to provide an address setup for the I/O device), the IO
state machine asserts ctb_ior_l.
7. After a delay (imposed to provide the read access time for the slowest I/O
device on the board), the IO state machine negates ctb_latw_l to latch the
read data in the IO_D latching buffer. ctb_ior_l negates one cycle later, so
that there is a positive data hold time at the latch.
This read cycle is a read of the PIT, which drives data on io_d[15:8]. The
register is uninitialized, so the value read back is OxXX.
8. After a delay (imposed to· provide an address hold time for the I/O device), the
IO state machine asserts ctb_io_ack to the Main state machine to terminate
the cycle.
9. ctb_do_io negates, and the IO state machine returns to idle.
10. The CPU starts a write cycle, and starts up the IO state machine as before.
This causes ctb_do_io to assert again, so that it was only negated for a
single cycle. This shows that ctb_do_io is guaranteed to negate, even when
non-sequential back-to-back CPU cycles are performed.
11. The IO_D bus is driven with the CPU's write data when ctb_io_wroe_l
asserts. In this back-to-back read-write pair, 3 mclk cycles have elapsed
since the data bus was turned off for the previous read. 8 mclk cycles have
elapsed since ctb_ior_l was negated for the previous read. This ensures that
there is no tristate overlap (bus contention) on the IO_D bus.
12. After the address setup delay, the IO state machine asserts ctb_iow_I for
long enough to meet the data-in requirement of the slowest I/O device.
13. ctb_latw_I asserts for write cycles, but this is simply a side-effect of the state
machine implementation and it serves no useful purpose. None of the data
bus latches are used to latch data during a write.
14. After the address hold delay, the IO state machine asserts ctb_io_ack,
causing the Main state machine to terminate the cycle.
15. The CPU starts a read cycle, which proceeds as before.
This time, the PIT register is initialized and the value OxOO is read back.
Since the PIT drives io_d[15:8], the io_d bus shows the value OxOOZZ. The
CPU data bus eventually shows the value OxOO:XXOOXX.
16. The sequencing of ctb_io_wroe_l and ctb_io_rdoe_l ensures that no tristate
overlap occurs.
ISAMEM cycles behave identically to ISAIO cycles, except that ctb_memr_I and
ctb_memw_l are asserted rather than ctb_ior_I and ctb_iow_I.

Simulation Waveforms 11-33

Simulation Waveforms
11.19 iordy

11.19 iordy
This waveform, shown in Figure 11-19, was produced using the simulation script
'do_iordy.cmd'.
This simulation shows the same read-write-read sequence as io (Section 11.18).
It shows how rdy can be used to extend the cycle length; the assertion time of
either ctb_ior_I or ctb_iow_I.
rdy is a open-collector signal with an associated pull-up resistor. Any I/O device
can negate rdy during an ISAIO cycle. Ifrdy is never driven during an access,
the access completes with a :fixed cycle time. If rdy is negated during a cycle,
the assertion of ctb_ior_I or ctb_iow_l will be extended until rdy asserts. When
rdy asserts, the cycle will terminate with exactly the same sequence as an
unextended cycle.
rdy can transition asynchronously; CTB contains synchronizing logic for this
signal.
ISAMEM cycles can be extended, using rdy, in exactly the same way.

11.20 iozws
This waveform, shown in Figure 11-20, was produced using the simulation script
'do_iozws.cmd'.
This simulation shows the same read-write-read sequence as io (Section 11.18). It
shows how zws_I can be used to truncate the cycle length; the assertion time of
either ctb_ior_l or ctb_iow_l.
zws_l is a open-collector signal with an associated pull-up resistor. Any I/O
device can assert zws_l during an ISAIO or ISAMEM cycle. If zws_l is never
driven during an access, the access completes with a :fixed cycle time. If zws_l
is asserted during a cycle, ctb_ior_l or ctb_iow_I will be negated as soon as
possible. Once asserted, zws_I should remain asserted until the ctb_ior_I or
ctb_iow_l strobe has negated.
zws_l can transition asynchronously; CTB contains synchronizing logic for this
signal. The synchronizer limits the maxim.um time between zws_l asserting and
a cycle terminating.
Figure 11-20 shows that the minimum ISAIO cycle time can be achieved by
asserting zws_l at the same time as ctb_ior_l or ctb_iow_I. In practice, an 1/0
device must decode its address before asserting zws_l.
ISAMEM cycles can be truncated, using zws_I, in exactly the same way.

11.21 iorfrdy
This waveform, shown in Figure 11-21, was produced using the simulation script
'do_iorfrdy.cmd'.

11-34 Simulation Waveforms

.,,

ICPU_MCLK
A

BYTES

....

D
BUF_A

mw_n
ro_n
Hf>IC/\

llt.Jl·tJ>
<:1'11_111tl-:C,LI•
Cl 11J_Cl1l;

C'I'/\ WAY'I' I.

lt:l'IJ=Wltl1'~
HAJll_HH

;

r:1'A \C'l'A \l)'.>_l>HAH
ic·1·A \C'rA \llHAM_AcK

;CTA_UUP1>_wno1c1.
,C1'A_Hlll-"D_RDOl:!_I.
iCTA_BUPIJ_RDO_I,
rT/\_BUl-"l>_WHG_I,
icTA_RAS_I,

OQXX

I: zzzz : x:
ICC

--oe

i :c i

l(!)(X

. :JI

:x
..x

. ...ll

;

....
....

.!,,

:i~ -·co

Hl'IWll_HM
IO_HM

xx.
00
oozz

~ ~ ' ~~· : ': ! i ! ll'f ! : f : : ; : : : !
~=:::=:::: nn : I :

.}1.._.

llHAM_m·I

c1·A_11.1mc_1,

:c •

cii'
c

1----f:

·~

·a~~ '. .'. '. l l ~:

:....2!.

:-t

.. ~

.·~

·r

:![

lc1'A_CAS_I,
lc'r/\_SKl,_C()I,

HUX_A
IC:TA_l>RAH_WB_l~

CTn_cl.KBY"/

CTA_IX>_IO

!c·rn_IO_ACK
CTU_JJ\TW_I,

.
.

~~~
_r.
:i.
""!l

.
I

.
0

•

CTB_I.ATB_L

"-.-

PAl<A
ICTIJ_to_HOOE_L

i------7l

::Jl

1CTH_IO_WRo•:_I,
I
ICTD_MEMR_I.
\CTB_l1EMW_L

!'o.
3
c:

aa·
::J

~
~

.......
~

iCTB_IOR_I,

:cTH_1ow_1,

!lcTn_Fr.Ar.11_wn_L

?.WS_I.

ITIHBR

;CTB\CTD\CLR_'rIHER

nov

i---:-t

:
10u

r:-t___;___;.f

10.Su

ITICPU_MCLKl

Time (Seconds)

;____r:.
.

3·
c

_n;

CTO\CTO\TRICK_WR

..
.

19u

...2:.

...xxxxxx

7t__;_J

iordy

/1un·/t1flarn/cronk/vl_nx1>/ahanl 10/rov21.!J?!

~
0

..a. ::I

~;:

..a.<
-·CD
0 O'
:::i..,
a. 3
'< "'

...i.
...i.

~r
c

ei:

5·

;:,

=·

ca·c
~·
0:
:
:===xx
;
:
:x:::JC
x
x
c::x!J
;

l~PU_MCLK

JO( :

BYTES

:JXX·

BUF_A

::x

IO_D

:xx:.

HOH_A

boxxooxx •

::x

:x:·

DIJP_ll

IU>l-1_1>

9022

xxxtc

1-~

1c:1•1J_WHl'l'I·:

_n:

MAlll_!Ol-1

:C'l'A_WAI'l'_J,

ooxxooxx • x

i---,

,CPU_H1mo_1.

xxxxoOICx

lc1"1_c1.1··

-c:

FXXXKXXC
•
•
x:JC
p
:
:
K:x
xx~xooxx
.[JO(
xxxxooxx
D:
!Pxx>l.lcxxc!:
~
xxx¥o•xx ·¥
c::::= ·
xxxxooxx ·
·c
: zzzz :
:
ooxx :
:
O:
xxxxc
l()(
i
~......,i....-~~·..-~~-..~~~..--~~~~~~r.
.~

c:: :

c:::

iC1'J\ \C'l'A \IX.»_UUAM

1c:·rA_UU(ll}_WltoB_I.
C'l'A_DUPl)_RIXJl-!_J,
I
C'l'A UUl'U Hl>G (,
C'l'A=BUl,.D=WRG=I,

IC'l'A_RAS_f,

.l,

_xxxJC

~·
: r1 (I)

: ~:--:

·~

.·:a:

.....
.....

::.x:

1--f

jC:'J'A_A1>::c_1,
:'J'A \c:'fA \f>HAM_ACK

"Tl

•

-g__

xx%xooxx (

•

..r:t

r-:-i

1u:nm1_sH

'. FixxxxX<:
: - •:

l>HAlL~m

10_:;1-1

•
:

•

C1'A CAS I•

lc.,.,.=s•:i.=co1.
MU><_A
1cTA_llRAH_w1-:_1.

·CTn_cl.KOY"I

CTA_IXJ_JO

;C'rB_IO_ACK

__f

iij
L...:..J

l'CTH_LATW_I,
CTD_LATD_L
PAKA

c1•n_1o_RllOE_1.

CTD_IO_WROE_t,
CTD_HF.HR_L

CTBJIF'..HW_I,

C'rD_IOR_L

.:r

lcTn_row_L

'1cTn PLASH wa_t.
,C1'U\CT8\TRICK_WR

RDY

zws_t.
ITIHER

J<='rD\CTll\CJ.ll_Tif.llm

t9.6u

:
19.7u

:n:
19.Bu

':
19,9u

:n:

2ou

[T(CPU_MCLKI

Time (Seconds)

20. tu

1
20.2u

:
20.lu

.-'

f:l

20.4u

iozws

/_usr /~~•r•/crook/vl_axp/obaa 110/ rav2 /epo

-en
.... _,

~3
..a.c

-·ii
0,...

:a.
.... -·
0
a.
:::s
'< ;e
m

3
tn

CPU_HCLK

ca·c

A
BYTES

.-ooxxooxic
:c.

:.x:

:x: ca

BUF_A
DUl•"_I>

"'OOX

::x::

:x:

10_1>

1m1-1_n

icPu_mmv_r.
rl'lJ_Cl,fo"

C1'/\_WAl"l'_J,
I

fµ
h

o)lzz

xx%xc

JQC

HOM_A

oo~x

xX)txc

zz.

:
:

n
.
m-

Cl>IJ WIU'l'P

lw. 1~_m1

zzzz:
XX

:
:

X::

zzzz:

.xx:=
: zz

oozz "
:c

6'
:::&.

IO_SH

-g~:

(,
IC1'A_Al>SC
C1'A\CTA\l>O_DRAH

C!)C:

;

•

;

•:_x__:!

'-.:-

om-

llHAM_SM

HPRSH_mt

.n ~

....
....
it,
....

(3)(

......

: L..j

CT/\ \CT/\ \l>RAH_ACK
CTl\_TIUFO_WHOB_I,

ICTA_IJUFo_nooE_L
CTA_DUPO_ROO_t,
CTA_DU(•'O_wna_L

'c•rA_RAS_I..
ICTA_CAS_L

iB : : tr:: : 8
m

m
s:-i

·"

ICTA_SEL__CO(,

_rl

I:L

·n

:JQ:X

·"

r--i_

MUX_A

lcTA_ORAM_WB_r.
1

:cTn_cLKDY7

:cTA_OO_IO
:CTO_IO_ACK

iCTU_t,ATW_L

: L

•

'
I

lcTD_l.ATn_r.

·::!:

PAKA

;cTD_IO_ROOR_J,
CTO_IO_WROR_I,

F:l

iCT£\_HEHR_l1
iCTH_HEMW_l,

fl)

'cTD_IOR_I,

(/)

3·
c:

~
0

Fl.ASH WR f,
IC'rD
CTD\CTD\1'RICK_WR

ROY

zws_1.

ITIHlm

,CTU\CTB\Cl,ll_TIMER

!2.
0

~
....
....
~

3·

CTD_IOW_I,

r=i:: :

..
7.1u

J.l
0

1.:
0

:::x:xxxxxx:::!

·--

~
21. 5u

IT(CPU_HCLK)

Time (Seconds)

22u

:::::!:

JOOOOOC
. L...___;_J
iorfrdy

/uar /uaera/crook/Yl _axp/obea l 10/rev2 /ape

i6"

.... :s

~~
....
<

-·CD
0 ....
::i. 0

...a. ...3

'< fl)

Simulation Waveforms
11.21 iorfrdy
This simulation shows the same extended read-write-read sequence as iordy
(Section 11.19). It shows refresh cycles happening in parallel. This demonstrates
that DRAM refresh activity is not held off during (potentially long) JJO cycles.
Notice that DRAM refresh cycles do not cause any activity on do_dram or
dram_ack.

11.22 iotrick
This waveform, shown in Figure 11-22, was produced using the simulation script
'do_io2.cm.d'.
This simulation shows a read-write-read sequence like io (Section 11.18). It
shows read and write cycles to internal registers in the CTB control logic. These
registers (the trickbox registers) are decoded in the ISAIO space, so ctb_ior_l and
ctb_iow_l strobes occur. A decode within the CTB logic generates the trick_w
pulse which performs the register write.
The waveform shows the sequence:
1. The CPU read starts and causes ctb_ior_l to assert.
2. The JJO device in CTB drives a data byte of OxOf on io_d[7:0]. The IO_D
buffer duplicates the data from io_d[15:0] onto both buf_d[31:16] and buf_
d[15:0]. Since io_d[l5:8] is fioating (tristate), unknown data (X) is driven
on the associated bytes of io_d. Therefore, buf_d[31:0] drives the value
OxXXOfXXOf. This value is driven from buf_d[31:0] onto the CPU data bus,
d[31:0].
3. The IO state machine negates ctb_latwJ to latch the read data in the IO_D
data buffer latch. On the next clock cycle it negates ctb_ior_l, causing the
JJO device in CTB to tristate its data bus.
4. io_d[7:0] goes tristate, and therefore the whole ofio_d[15:0] is now tristate.
5. ctb_latw_l only latches data in the low half of the IO_D buffers, the half
that drives buf_d[15:0]. The half that drives buf_d[15:0] onto buf_d[31:16]
remains transparent, and so it drives unknown data. Therefore, the value
on buf_d[31:0] (and therefore, d[31:0]) changes from OxXXO:tXXOf to
Ox:XXXXXXOf. When the cycle completes, this is the value that the CPU
reads.
6. The CPU write starts.
7. The IO state machine generates a pulse on trick_wr during the final cycle of
ctb_iow_l. trick_wr is only used within the CTB control logic, and is used
to latch write data for the Trickbox registers. (Data is actually latched into
the Trickbox register two clock cycles later.)

11-38 Simulation Waveforms

l~PU_MCLK

:!!

ca
c

BYTES

Cil

....
....

BUF_ll

mw_n

~
§:
...
c;·

IO_l>
llOM_/\
HOM I>
11•1 11J_l-llm(LJ,

;t·11o_c1.1··
1t~·rA_WA f'l'_f,

!<:l•U_WHl'l'I-!

MAlll_::H

l>HAM_:>M
RPHSll_:;M
ro_~:M

ICTA_Al>!;C'_I.

IC'f/\ \C'l'A \ IX>_l>ltAM

,C1'/\ \CT/\ \l>IU\l·l_ACK
lc•rA_IJUPO_WllUB_I.

~
:

lc·1·A_um~1>_RIX)~(.
c-rA_l!UFD_1ttx;_1,

CTA_IJUPO_w1m_1,
CTA_RAS_I,
CTA CAO f,

,C'f/\_Sf!f,_COh

HUX_A

C'fA_ORAJl_WR_J,
ICTD_Cl.KDY'/
CTA_OO_lO

C'rll_IO_llCK

tt=1
.

__rj

• • • •1

-- _: ___r.--i
Ct
:

r---i

.: --.

·..fl

.r--L

. .: .
·"

.
.
.

::!!!!:

~
h_

<TI

CTD_l 11\'fW_L

CTR_l,A'fll_I,
l'AKA

CTO_IO_RIX>B_L

lCTD_1o_WROICl1

-,-

JQ:)(

.:f

CTD_Hl-!HR_l,
CTD_Hl~HW_f,

(/)

~~r
c:

aer
:J

ICTR_IOR_f,

ICTB=Pl.A;ll_Wlt_I.

3·
c

17:

a6'

ROY

?.WS_I,

TIHf!lt
IC'fB\CTD\Cf,ll_'l'IHBR

~
....

,T(CPU_HCLKJ

lcTD\C'fR\TRICK_WR

~
!!!.
0

...-~----'- ( 1)

IC'flJ ]OW ••

L___~~
.
.
t

~·~
.
_

•

~~
.

23.Su

2Ju

Time (Seconds)

iotrick
/uar/uaot·a/crook/vl axp/obsall0/rov2/spe

..... :s

9'><

-·CD

20'
.., ..,
c;· 3

~(I)

A
Configuration Guide
This appendix describes:
•

The default configuration of the board

•

The settings for all links and jumpers

•

The pinout of all connectors

•

The meaning of all LEDs

•

The cables required for connection to the board

•

How to upgrade the DRAM SIMMs

A.1 Default Configuration
Use this section to set your board back to the factory default settings.
The default hardware configuration of the EBSA-110 is for a 161.9 MHz CPU
running at a core voltage of 1.SV, with a 53.9 MHz external bus. To set this
configuration, remove any jumper on Jl and fit jumpers to these pins on J4: pin
1-2, pin 3-4, pin 7-8, pin 13-14.
The default software configuration of the EBSA-110 is to boot the ARM remote
debugger from Flash. To set this configuration, remove any jumpers from J2 pins
1-2, 9-10, 11-12 and 13-14.

A.2 Description of All Jumpers
2-pin jumpers are used to configure behavior th.at you may wish to change. Jl
is a 2-pin jumper to configure the CPU core voltage, J4 is a 16-pin jumper block
(accommodating 8 jumpers) that configures clock frequencies. J2 is a 16-pin
jumper block that configures software boot options. J2 is also used to connect
to the speaker and external switches. Figure A-1 shows the settings for these
jumpers, and Table A-1 describes the function of each jumper.

----------------------~ Note -----------------------The EBSA-110 supports a range of core frequencies for the SA-110
microprocessor. Ensure that you do not try to run your board with a core
frequency that exceeds the specification of the SA-110 that is fitted.

Configuration Guide A-1

Configuration Guide
A.2 Description of All Jumpers
Figure A-1 EBSA-110 Configuration Links

KEY
Jumper f i t t e d
Jumper not

fitted

Jumper does not
t h i s function

affect

v•
~J4

Speaker
J1.

vcore

Fcore

Fbus

~
.

IIIfiliiIIIfilI +1.SV

88.3MHz

44.1MHz

~+1.SV

95.6MHz

47.SMHz

lfilCTil1IfilIII

99.4MHz

49.7MHz

~+1.SV

106.7MHz

53.3MHz

~+1.SV

143.SMHz

47. 8M:-l:z

~+1.SV

150.9MHz

50.3MHz

~+1.SV

161.9MHz

53.9MHz

OOJJU Boot image 1
OOdJ1) Boot image 2
OOJiil} Boot image 3

~+1.SV

169.3MHz

42.3MHz

IIU11J

~+2.0V

191.3MHz

47.SMHz

IIl1hilJ Boot

~+2.0V

202.4MHz

50.6MHz

~+2.0V

213.4MHz

53.3MHz

rruJJ]:Jdi] +2.0V

228.1MHZ

45.6MHz

~
~ +2.0V
rmimifJ1) +2.0V

242.SMHz

48.SMHz

257.6MHz

51.SMHz

276.0MHz

46.0MHz

~ +2.0V

287.0MHz

47.SMHz

0
0
0

+ 1 _ sv

+2.0V

A-2 Configuration Guide

TURBO Switch
RESET switch

mm.

Boot

image

image 4
image

OOJilh) Boot image 6
OO!illD Boot image 7
-

TURBO Switch
boot
from FLASH when OFF
from EPROM when ON.

Configuration Guide
A.2 Description of All Jumpers

TableA-1 Jumpers
Reference

Function

1-2

J4
J4
J4

1-2
3-4
5-6

CPU Core voltage. When removed, the CPU core voltage is
configured to +2V. When fitted, the CPU core voltage is reduced to
+1.5V.
cpu_mccfg[2] is tied LOW when this jumper is fitted.
cpu_mccfg[l) is tied LOW when this jumper is fitted.
cpu_mccfg[O] is tied LOW when this jumper is fitted. cpu_
mccfg[2:0] set the CPU bus clock as a sub-multiple of the CPU
core clock.

1·2

3-4

5-6

fit
fit
fit
fit
fit
fit
fit
J4
J4
J4

fit
fit

fit

mccfg

Divisor

111
110
101
100
011
010
001
000

core clock/9
core clock/8
core clock/7
core clock/6
core clock/5
core clock/4
core clock/3
core clock/2

7-8

cpu_cccfg[3] is tied LOW when this jumper is fitted.

9-10

cpu_cccfg[2] is tied LOW when this jumper is fitted.

11-12

cpu_cccfg[l] is tied LOW when this jumper is fitted.
(continued on next page)

Configuration Guide A-3

Configuration Guide
A.2 Description of All Jumpers
Table A-1 (Cont.) Jumpers
Reference

Function

13-14

cpu_cccfg[O] is tied LOW when this jumper is fitted. cpu_
cccfg[3:0] set the CPU core clock.
Frequency

7-8

9-10

11-12

13-14

cccfg

MHz

fit

0000

88.3

fit
:fit

fit

0001
0010

95.6
99.4

fit

0011

106.7
143.5

fit
fit
fit

fit

fit
fit

fit
:fit

fit

fit
:fit

fit

1000

fit

1001
1010

fit

1011
1100

fit

1101
1110

fit
fit
fit

0100
0101
0110
0111

1111
J2
J2

1-7
2-4

6-8

J2
J2

9-10
11-12

A-4 Configuration Guide

150.9
161.9
169.3
191.3
202.4
213.4
228.1
242.8
257.6
276.0
287.0

Loudspeaker connection.
Reset. When these pins are connected, the system will be held in
reset. Normally, this is wired to a reset switch.
EPROM_BOOT. When this jumper is removed (default), the initial
bootstrap code is read from the Flash ROM. When this jumper is
:fitted, the initial bootstrap code is read from the EPROM. This
could be wired to a switch so that this selection can be made from
the front panel, without removing the system's cover.
SOFTI3: Select boot image.
SOFTI2: Select boot image.
(continued on next page)

Configuration Guide
A.2 Description of All Jumpers
Table A-1 (Cont.) Jumpers
Reference

Function

13-14

SOFTil: Select boot image.
J2:13-14

J2:11-12

fit
fit

J2:9-10

Action

fit

Boot image 0
Boot image 1
Boot image 2

fit

Boot image 3
Boot image 4

fit

Boot image 5

fit

Boot image 6
Boot image 7

fit
fit

15-16

fit

One or more pairs of these pins could be wired to switches so that
different images could be selected easily.
SOFTIO: The function of this link is unassigned; it may be freely
used by application software.

A.2.1 Supported Clock Configurations
Figure A-1 shows which combinations of core and bus frequency are supported by
the EBSA-110. The clock configuration is set by configuring jumpers on J4 and
Jl.
It is possible to run with higher MCLK divisors (slower MCLKs) than those
shown but the DRAM timing will be sub-optimal and the DRAM refresh interval
will need to be reprogrammed to avoid data corruption.

A.3 Description of All Links
Configuration links are pieces of copper etch on the PCB that have been layed out
in such a way as to make them easy to cut (with a scalpel) and reconfigure (to

an adjacent pad). They are provided to allow the experienced hardware engineer
to experiment with different modes of operation of the EBSA-110. The links are
shown in Table A-2. Lin.ks with a reference designator greater that 100 are sited
on side 2 of the board.
Table A-2 Links
Reference

Schematic
Sheet

ELl

Description

By default, channel 1 of the Programmable Interval Timer
is clocked at 1/7th of the bus frequency. Cutting this link
isolates the channel's clock so that an alternative :frequency
can be driven in.
(continued on next page)

Configuration Guide A-5

Configuration Guide
A.3 Description of All Links
Table A-2 (Cont.) Links
Reference

Schematic
Sheet

EL2

By default, channel 2 of the Programmable Interval Timer
is clocked at 1/7th of the bus frequency. Cutting this link
isolates the channel's clock so that an alternative frequency
can be driven in.

EL101

PWRSLP_L input to CPU. Default is HIGH, alternative is
LOW.

EL104

EL105

TCK_BYP input to CPU. Default is LOW, alternative is
HIGH.
APE input to CPU. Default is LOW, alternative is HIGH.

EL106

SNA input to CPU. Default is HIGH, alternative is LOW.

EL107

EL108

Default is to route nMCLK from the CPU to on-board logic.
Cutting this track would allow the on-board logic to be driven
from an alternative clock source.
If SNA (see above) is reconfigured to run the CPU bus
interface asynchronously to the CPU core clock, these pads
allow the bus clock to be driven into the CPU via a coaxial
cable from an external signal generator.

EL109

DBE input to CPU. Default is HIGH, alternative is LOW.

Description

ELllO

ABE input to CPU. Default is HIGH, alternative is LOW.

ELlll

SSRAM pin 14 input. Default is LOW, alternative is HIGH.
This wiring is intended to accommodate next-generation
SSRAMs. Some SSRAMs have +3V power on pin 14, others
have OV. The default is correct for Micron C4 and D7 parts.

EL112

CONFIG input to CPU. Default is HIGH, alternative is LOW.

EL113

SPDF input to CPU. Default is HIGH, alternative is LOW.

EL114

MSE input to CPU. Default is HIGH, alternative is LOW.

EL115

TESTCLK input to CPU. Default is LOW, alternative routes
TESTCLK to output of on-board oscillator. This arrangement
has been designed to allow the CPU to be driven from a 1x
clock either by an on-board oscillator or via a coaxial cable
from an off-board signal generator.

A.4 Connectors
Refer to the circuit schematics for the pinout of connectors. The connectors are
shown in Table A-3.
Table A-3 Connectors
Reference

Schematic
Sheet

Description

J21

COMl: 10-way male IDC for connection to RS232 serial port.

J23
J24

12
12

COM2: 10-way male IDC for connection to RS232 serial port.

A-6 Configuration Guide

LPTl: 26-way male IDC for connection to parallel printer
port.
(continued on next page)

Configuration Guide
A.4 Connectors
Table A-3 (Cont.) Connectors
Reference

Schematic
Sheet

Description

JTAG: 14-way male IDC for connection to ARM debug box.

J22

J20
J25

21
15

PCMCIA: dual-socket PCMCIA connector. Sock.et A is the
lower socket (closer to the board). Socket Bis the upper
sock.et.
Power: 12-way male connector for power.
Ethernet: shielded female RJ45 (modular jack) for connection
to lOMbps 10-BaseT Ethernet.

A.5 Debug Connectors
The EBSA-110 is layed out with a number of debug connectors suitable for
connection to a Tektronix DAS logic analyzer. These connectors may not be
fitted as standard. Refer to the circuit schematics for the pinouts of individual
connectors. On all connectors, all odd-numbered pins are connected to OV. The
debug connectors are shown in Table A-4.
An alternative use for these connectors is that it allows an expansion board to be

attached to the EBSA-110, as described in Section 10.4.
Table A-4 Debug Connectors
Reference

J7
J9
JS
JlO
J18
J14
J15
Jl6
Jll
J12
Jl9
Jl7
Jl3
J26
J27
J28
J29

Schematic
Sheet

4
4
4
4
4
4
4
4
4
4
4

Description

Buffered data: buf_d31:24]
Buffered data: buf_d[23:16]
Buffered data: buf_d[15:8]
Buffered data: buf_d[7:0]
Buffered address: buf_a[29:22]
Buffered address: buf_a[21:14]
Buffered address: buf_a[13:6]
Buffered address: buf_a[5:2], buf_be[3:0Ll
1/0 data: io_d[15:8]
110 data: io_d[7:0]

Miscellaneous control signals
Miscellaneous control signals and CTA observability

4
4

Miscellaneous control signals and CTB observability
2x8 header wired to gnd as logic analyzer reference

4
4

2-pin header;cpu_mclk and gnd
2-pin header;cpu._mclk_l and gnd

2x8 header wired to gnd as logic analyzer reference

Configuration Guide A-7

Configuration Guide
A.6 Debug Pick-up Points

A.6 Debug Pick-up Points
Debug pick-up points are etch positions for individual test pins. These were used
for high-speed signals where it was undesirable to increase the etch length by
routing the signal to a central connector. The debug pick-up points are shown in
Table A-5.
Table A-5 Pick-up point

Reference
TPl
TP2

TP3
TP4
TP5
TP6
TP7
TP8
TP9
TPlO
TPll
TP12
TP13
TP16
TP17

schematic
sheet
22
22
4
20
20
20
4
4
4
4
4
4
4
16
16

Description

+1.5V/+2.0V test/sense point, close to CPU
OV gnd reference, close to CPU
cpu_lock
+1.5V/+2.0V test point, close to regulator
+3.3V test point, close to regulator
OV gnd test point
cpu_seq
cpu_clf
cpu_write
cpu_mreq.J

cta_wait_l
cpu_a[30]
cpu_a[31]
cia_iocs16_1
cia_memcs16_1

A.7 LEDs
The EBSA-110 has 5 LEDs for displaying status information. The LEDs are
positioned on the back edge of the board. When the board is cased, the LEDs
are only visible from the rear of the unit. The order of the LEDs is shown in
Figure A-2. The LEDs provide this information:

A-8 Configuration Guide

Configuration Guide
A.7 LEDs
Figure A-2 Position of LEDs

LINK
OK

RX
POL OK

Debug

RED

YELLOW

GREEN

RED

•

DEBUG (red) - this LED is used by the on-board diagnostics and by the ARM
remote debug stub. When the on-board diagnostics are enabled, it :flashes
quickly 8 times when the board is reset or power-cycled. When the ARM
remote debug stub is enabled it comes on for approximately 0.5s when the
board is reset or power-cycled and is then extinguished.

•

TX (red) - this LED is illuminated to indicate transmit activity on the
Ethernet port.

•

RX_POL (yellow) - this LED is illuminated to indicate correct receive polarity
on the 10-BaseT link. If this LED is extinguished, the link will still operate
correctly, since the Ethernet controller can automatically reverse the receive
polarity.

•

RX (green) - this LED is illuminated to indicate receive activity on the
Ethernet port.

•

LINK_OK (red) - this LED is illuminated when 10-BaseT link status is good.

A.8 Cables Within the Enclosure
The EBSA-110 uses :flying leads to connect from the board to the power supply
and to the connectors mounted onto the chassis.

A.8.1 Power Supply
The EBSA-110 power connector, J20, is on one edge of the board.
PC-style power supplies usually have a pair of power connectors. These
connectors are polarized. When viewing the EBSA-110 so that the CPU is in
the bottom right-hand corner of the board, the power connectors are positioned
correctly when there are 3 red cables on the left and 4 black cables in the centre.
The power supply cables may be labelled 'P9' on the left-hand connector and PS
on the right-hand connector.
The silk screen around J20 is marked to show the VDD (red), GND (black) and
+12V (yellow) connections.

Configuration Guide A-9

Configuration Guide
A.8 Cables Within the Enclosure
A.8.2 Serial Ports
The COM ports on the board are connected to 9-way male D-type connectors on
the bulkhead of the enclosure. The cable is 10-way ribbon cable with a 9-way
male D-type IDC on one end and a 10-way female header IDC on the other end.
The connectors are aligned so that pin 1 on the D-type is connected to pin 1 on
the header through pin 1 of the ribbon cable.

A.8.3 Parallel Port
The LPTl port on the board is connected to a 25-way female D-type connector on
the bulkhead of the enclosure. The cable is 26-way ribbon cable with a 25-way
female D-type IDC on one end and a 26-way female header IDC on the other end.
The connectors are aligned so that pin 1 on the D-type is connected to pin 1 on
the header through pin 1 of the ribbon cable.

A.8.4 Reset Switch
The reset pins on J2 are connected to a front-panel reset switch by a 2-pin header
and cable.

A.8.5 Turbo Switch
Many PC Cabinets have a 2-position 'TURBO' switch on the front panel. This can
be connected to pin 2-4 on J2 to allow this switch to select between EPROM boot
or Flash boot. Alternatively, it can be connected to pins 9-10 on J2 to allow this
switch to select between Flash images 0 and 1 after reset.

A.8.6 Loudspeaker
The speaker pins on J2 are connected to the chassis' speaker by a 2-core cable
terminated in a 4-pin connector. The speaker is wired to pins 1 and 4 of the
connector and can be connected to J2 with either polarity.

A.9 Cables for External Connection
The EBSA-110 uses standard,·readily available cables to attach to external
equipment.

A.9.1 Serial Ports
The COMl and COM2 serial ports on the EBSA-110 are wired as they would be
on a PC, therefore they are wired as DTE (data terminal equipment) ports. Use a
null-modem (twist) cable to connect a terminal or host system to this port.
A suitable cable will have a female 9-way D-type connector on one end and a
female 9-way or 25-way (depending upon the connector on the other system) on
the other end. Table A--6 shows the wiring of a suitable cable.
Table A-6 Null-MoDem Cable
(9-way) Connector

(25-way) Connector

(9-way) Connector

A Pin

B Pin

Description

Gnd- Gnd

3
7

T:xD - RxD

RTS- CTS

(continued on next page)

A-10 Configuration Guide

Configuration Guide
A.9 Cables for External Connection
Table A-6 (Cont.) Null-MoDem Cable
(9-way) Connector

(25-way) Connector

(9-way) Connector

A Pin

B Pin

Description

6,1

20
2

4
3
7
6,1

DSR, DCD - DTR
RxD-TxD
CTS-RTS
DTR - DSR, DCD

2
8
4

6,8

A.9.1.1 Serial Cable for SUN Workstation
ARM suggest a cable with the wiring shown in Table A-7 for connection to the

25-way connector on a SUN workstation.
Table A-7 SUN Null-MoDem Cable
(9-way) Connector

(25-way) Connector

A Pin

B Pin

Description

2
3
5

2
3

RxD-TxD

Gnd-Gnd
RTS-CTS
RTS-CTS
DTR-DSR-DCD
DTR-DSR-DCD

7-8

4-5
4-6-1
20-6-8

TxD-RxD

A.9.2 Parallel Port
The LPTl parallel printer port on the EBSA-110 is wired as it would be on
a PC. With suitable software, it can be used to drive a parallel printer or for
bidirectional data exchange.
To use the port for bidirectional data exchange with a PC, use a bidirectional
parallel cable. Such cables are readily available and are often described as
laplink or interlnk cables. A suitable cable will have a male 25-way D-type
connector on each end. Table A-8 shows the wiring of a suitable cable.
Table A-8 Bidirectional Parallel Cable
(25-way) Connector

(25-way) Connector

A Pin

B Pin

Description

2
3
4
5
6
15

15
13
12
10

Data 0
Data 1
Data2
Data3
Data4
Error

(continued on next page)

Configuration Guide A-11

Configuration Guide
A.9 Cables for External Connection
Table A-8 (Cont.) Bidirectional Parallel Cable
(25-way) Connector
A Pin

(25-way) Connector
B Pin

12
10

ACK
BUSY

GND

Description

Online
Paper End

A.9.3 Parallel Port Loopback
The EBSA-110 diagnostics allow the optional use of a loopback connector on the
parallel printer port. This loopback connector can only allow a partial test of the
port. A suitable loopback can be made by wiring a male 25-way D-connector in
accordance with Table A-9.
Table A-9 Parallel Port Loopback Connector
Connect Pins

Description

2-15
3-13

Data 0 to Error

4-12
5-10

Data 2 to Paper Out
Data3 to ACK

Data 1 to Online

A.9.4 Ethernet Port
The connection to the Ethernet port is via a standard unshielded twisted pair
Ethernet cable, terminated at each end with an RJ45 modular jack plug.

A.9.5 JTAG Port
The wiring of the JTAG port is shown in Table A-10. The JTAG port operates at
5V TTL levels.
·
Table A-10 JTAG Cable
Pin

Type

Description

Pulled up to +5V through a 33R resistor

GND

3
4
5
6
7
8
9

Input to board

TRST_L

Input to board

Not connected
TDI

GND
Input to board

TMS

Input to board

GND
TCK
(continued on next page)

A-12 Configuration Guide

Configuration Guide
A.9 Cables for External Connection
Table A-10 (Cont.) JTAG cable
Pin

Type

Description

GND

Output from board

TDO

Input to board

SRST_L - asserting this signal resets the
board

Connected to pin 1

GND

A.10 Upgrading the DRAM SIMMs
The EBSA-110 can accommodate 2 DRAM SIMMs. If only one is fitted, it must be
fitted in position J6. If two are fitted, they must be of the same type and density.
The EBSA-110 diagnostics report:
•

The DRAM size

•

The type of DRAM fitted (EDO or BEDO)

•

The number of DRAM SIMMs :fitted

Before handling DRAM SIMMs, ensure that you are observing the handling
precautions described in Section 1.2.
To upgrade the DRAM SIMMs, power-down the system, remove the cover and
click the new part(s) into the SIMM sockets, J5 and J6. The sockets are polarized
so the SIMMs can only be inserted in the correct orientation.
The DRAM memory size and type is automatically detected and configured by a
combination of on-board hardware and software.
·
After upgrading the DRAM SIMMs, run the EBSA-110 diagnostics to verify that
the new configuration has been recognized and is working correctly.
The EBSA-110 can support 60ns 72-pin 5V 32-bit DRAM SIMMs in three
densities: 1Mx32, 2Mx32, 4Mx32. Some suitable DRAM SIMMs are listed in
TableA-11.
Table A-11 Suitable DRAM SIMMs
Part

Type

Description

Generic

1Mx32 EDO

2 RAS, driven simultaneously

Generic

2Mx32 EDO

2 RAS, decoded from high-order address

Generic

1Mx32 BEDO

2 RAS, driven simultaneously

Generic

2Mx32 BEDO

2 RAS, driven simultaneously

Generic

4Mx32 BEDO

2 RAS, driven simultaneously

MT16D232M-6 X

2Mx32 EDO

Micron

MT4D232M-6 BES
MT8D432M-6 B ES

2Mx32 BEDO
4Mx32 BEDO

Micron
Micron

Configuration Guide A-13

B
Debugging a Broken Board
At some time in the life of your EBSA-110, you may find that it suddenly ceases
to function, due to mis-con:figw:ation or hardware failure. This section provides
some hints on tracking down the fault.

B.1 Basic Checks
•

Check that your power supply fan is running (a clue that the power supply is
working).

•

Check that the jumpers correctly set the core voltage and clock frequencies
(see Figure A-1).

•

Check that jumper J2, 2-4 (EPROM_BOOT) is not fitted.

•

Check that the chassis or chassis mountings are not shorting against the
board.

•

Follow the procedure in Section 1.4, if you have not already done so. Ensure
that any jumpers have been removed from J2 pins 9-10, 11-12, 13-14.

If the LED does not fl.ash at all and you have an EPROM fitted in U22, fit jumper
J2, 2-4 (EPROM_BOOT) and reset the board. If the LED flashes, this indicates
that the Flash PBL has become corrupt; follow the procedure in Section 8.3. If

the LED still does not flash, attempt to run the on-board diagnostics using the
procedure described in Section 8.4.
If the diagnostics will not start, refer to Section B.2. If they start but one of the

tests fails, refer to Section B.3.

B.2 Checking the Board
If your board is still showing no signs of life, perform these checks:

•

Check that all socketed components are properly seated in their sockets.

•

Check that all cables are correctly polarized and aligned.

•

Check that there are no stray cables within the enclosure that could be
shorting out.

To proceed any further, you will need access to an oscilloscope and a set of
EBSA-110 schematics. Check the following:
•

Power: +SV, +12V (from the external power supply) +3.3V, +2V (from on-board
regulators).

•

Clocks: osc3 (3.68 MHz), cpu_mclk_l (49 MHz-55 MHz), osc24 (20 MHz),
ctb_clkby7 (approximately 7 MHz).

•

Reset: check that rst_reset_l toggles when the reset switch is pressed, and
that buf_reset_l toggles as a result.

Debugging a Broken Board B-1

Debugging a Broken Board
B.2 Checking the Board
•

CPU activity: check for transitions on cpu_mreq_I when the reset switch is
released. If cpu_mreq_I asserts and stays asserted, see whether eta_wait_I
is permanently negated.

•

State machine activity: check for transitions on cta_do_io when the reset
switch is released. If cta_do_io asserts and stays asserted then see whether
ctb_io_ack is permanently negated.

•

Packer activity: check for transitions on the Flash (or EPROM) chip selects
and output enables. Check for transitions on the ROM_D data buffer control
signals.

If none of these things help you to find the fault, you probably need to use a logic
analyzer to track down the problem. Read Chapter 10 to get an understanding of
the operation of the board. Use the debug connectors and pick-up points to attach
your logic analyzer.

B.3 Diagnostic Failure
If your board is showing signs of life, but is failing diagnostics, then the :first
failure message from the diagnostics should provide some clue to the fault. If
multiple error messages cause the relevant message to scroll off the screen, try
using a virtual terminal with scroll bars (for example, the terminal emulator in
Microsoft Windows™).

B-2 Debugging a Broken Board

c
The Design Database
The EBSA-110 Hardware Developers Kit (HDK) includes a number of FAT-format
3.5" floppy disks which provide a (hardware) design database and a :firmware
database.
These databases are intended to help designers use the EBSA-110 design as a
starting point for their own designs.
The hardware design database includes:
•

A VIEWlogic® hardware design database

•

Simulation test scripts

•

A VHDL bus transactor model of the SA-110

•

A VHDL model of the synchronous SRAM used in the design

•

ABEL source files for the programmable logic

•

Layout drawings

•

Timing Designer waveforms and libraries

•

Simulation waveforms

The firm.ware database includes source tree and executables for:
•

The PBL

•

The bootp utility

•

The FMU

•

The ARM remote debugger stub

Refer to the README files on the floppy disks for more information.

The Design Database C-1

D
SA-110 Bus Transactor Model User's Guide
The SA-110 bus transactor model (BTM) was intended to help hardware
designers by providing an easy-to-use tool for generating bus cycles in a
simulation environment.
This appendix describes what the BTM is, how to instantiate the BTM into your
simulation environment, and how to use it.
Consider this example:
set_addr 00400000\h
do_wr 12345678\h
do_idle 1\h
do_rd 12345678\h
set_addr 00400004\h
do_rd aaaa5555\h
do_idle 1\h
sim 1000ns

This set of commands can be typed at the simulator command line. When the
'sim' command is given, the BTM performs 2 bus cycles. The first bus cycle is
a non-sequential write to address Ox400000. This is followed by a single idle
cycle (that is, the next bus cycle follows back-to-back). The second bus cycle is
a sequential read of 2-beats, starting at address Ox400000. Because there is no
'do_idle' command between the two 'do_rd' commands, they are performed as a
sequential cycle. The BTM mimics the SA-110 worst-case timing and monitors
the WAIT input during bus cycles, in order to control the cycle length. The
parameters to the 'do_rd' commands tell the BTM to check the data returned
during read cycles and report an error if there is a mismatch.
The BTM implements this functionality:
•

Performs sequential and non-sequential read and write cycles

•

Performs lock cycles

•

Allows arbitrary amounts of idle time between cycles

•

Provides data checking on reads

•

Reports transitions on fiq, irq, abort

•

Checks setup and hold times of abort

•

Reports configuration (bus mode, clock speeds, clock mode) after reset

•

Supports standard and enhanced bus modes

•

Supports synchronous and asynchronous clocking

•

Supports both APE modes (normal and FASTBUS)

SA-110 Bus Transactor Model User's Guide D-1

SA...110 Bus Transactor Model User's Guide
D.1 Instantiating the.Model

D.1 Instantiating the Model
This section assumes that you wish to use the BTM in your own design within a
VIEWlogic simulation environment.
The normal way of instantiating the BTM is simply to add the SA-110 symbol to
your schematic, and then wire it up.
In order to access the BTM from within your design, you must add an entry to
your viewdraw.ini that points to the subdirectory containing the BTM and its

associated files.
There are 2 versions of the SA-110 symbol (body). sarm..1 is automatically
generated from the VHDL source. It has bussed pins, and no PCB information.
To use the command files with this symbol you must attach the label 'sarm \ sarm'
to the symbol when you instantiate it. sall0.1 is a hand-generated symbol with
scalar pins; it includes PCB information like power/ground pins and pin numbers.
This symbol is hierarchical and instantiates the sarm.1 symbol via the schematic
page sallO.l. To use the command files with this symbol, you must attach the
label 'sarm' to the symbol when you instantiate it.
To use the BTM, you need copies of the command files in your project area.
Change directory to your project area and then execute the script get_sarm_
command_files (which is in the same subdirectory as the BTM); this will make
copies of the command files in your project area.
In order to use the BTM, your simulation ticksize must be set to lOps, because
some of the delays are specified to the resolution of 0.25ns. The simplest way to
do this is to create a file in your project area called viewsim.ini and containing
the line 'ticksize lOps'.
The BTM does not model the SA-110 PLL. It expects a clock at the core
(multiplied) frequency to be supplied on the CLK (and/or TESTCLK) input. The
value of CCCFG is reported after reset, but not used in any other way. MCCFG
is modelled, selecting the divisor. TCK_BYP controls whether CLK or TESTCLK
generates the MCLK When SnA is sampled asserted, MCLK and nMCLK are
generated and driven as outputs. For odd divisors, MCLK is modelled as low for
the longer period, and nMCLK is its Boolean complement. When SnA is sampled
negated, MCLK is tristated so that it can be driven in to the CPU. nMCLK is
driven to X in this mode.
Once you have followed these steps, you should be able to start a simulation.
When the BTM comes out of reset it should produce a start-up banner that looks
something like this:
SARM\SARM\BFM: Resetting all state ..
SARM\SARM\BFM:
SARM\SARM\BFM: --------------------------------------------------------------------SARM\SARM\BFM:
SARM\SARM\BFM: StrongArm Bus Transactor Model V0.14
SARM\SARM\BFM: Copyright (c) 1996 by Digital Equipment Corporation, Maynard, Ma. USA
SARM\SARM\BFM:
SA.'RM\SARM\BFM: APE is selecting FASTBUS address timing
SARM\SARM\BFM: CONFIG is selecting ENHANCED bus mode (masks/wraps/merges)
SARM\SARM\BFM: SnA is selecting SYNCHRONOUS MCLK (MCLK output)
SARM\SARM\BFM: TCK_BYP is selecting the PLL as the core clock
SA.'RM\SARM\BFM: MCCFG[2:0) is selecting an MCLK divisor of 3
SA.'RM\SARM\BFM: CCCFG[3:0J is selecting a core frequency of 161.9 MHz
SARM\SARM\BFM: SPDF is GROUNDED
SARM\SARM\BFM: --------------------------------------------------------------------SA.'RM\SARM\BFM:

D-2 SA-110 Bus Transactor Model User's Guide

SA-110 Bus Transactor Model User's Guide
D.1 Instantiating the Model
If you have problems instantiating the BTM, use the EBSA-110 design database
as an example of a working environment.

D.2 Command Reference
Ten commands are used to control the bus cycles produced by the BTM.

D.2.1 set_addr {address}
Set a (32-bit) address. The address applies to all subsequent bus operations until
another set_addr is performed (but see set_page below, which acts independently).

D.2.2 set_page {offset}
Set a (32-bit) page. The page applies to all subsequent bus operations until
another set_page is performed (but see set_addr, which acts independently).
The actual address used for the bus operation is the Boolean OR of the addr and
page values. The page will normally be set to 0. There are two situations where
it is useful to change the page:
•

General-purpose tests: if you write a command script that tests memory, you
can write the test to use memory at address 0, using set_addr, and never use
set_page within the test. You can then use set_page to set the start address
of the test. For example, on the EBSA-110 design, you would use set_page 0
and run the test once (to test the SSRAM) and then use set_page 40000000
and run the test again (to test the DRAM).

•

To put don't-care states into addresses: if you are writing a test to verify
address decodes, it is often useful to use X (don't-care) states. If you expect
that A29:A28 are not required for a decode, you could use the command
set_page OO:XXOOOOOOOOOOOOOOOOOOOOOOOOOOOO\ b and then use a number
of set_addr commands. This avoids the messiness of having to express every
address in binary.

The reason that a Boolean OR is used rather than an ADD, is that an ADD
operation prevents you from being able to use X (don't care) states with the same
flexibility that an OR provides.

D.2.3 set_bytes {byte masks}, set_size {size}
These commands are mutually exclusive. They are used to set the size mask for
read and write cycles.
When the SA-110 is configured with config negated (standard bus mode), the
set_size command is used, to control the state of the mas[l:O] outputs. set_size
takes a 2-bit argument, corresponding to the values required on mas[l:O] during
the access.
When the SA-110 is configured with config asserted (enhanced bus mode),
. the set_bytes command is used to control the state of the a[l:O] and mas[l:O]
outputs. These four signals behave as asserted-low byte enables. set_bytes
takes a 4-bit argument, corresponding to the state required on the byte enables
during the access. For example, a value of Oxc would correspond to the byte
lanes associated with data bits 15:0 being active (since the byte enable pins are
active-low).

SA-110 Bus Transactor Model User's Guide D-3

SA-110 Bus Transactor Model User's Guide
D.2 Command Reference
D.2.4 do_rd {expected read data}
This command is used to enqueue a read cycle at the current address and page,
and with the size mask. If the previous enqueued command was a read, then this
command will continue from the previous read as a sequential cycle.
When the read cycle completes, the data returned from the system will be checked
against the 32-bit parameter {expected read data} and an error message will be
generated if there is a mismatch. {expected read data} may include Z (tristate)
and X (don't-care) bits.
The BTM always checks all 32 bits of read data, irrespective of the size masks.

D.2.5 do_crd {expected read data}
This command behaves like do_rd, except that the CLF signal is asserted,
indicating to the system that the read cycle is a cache line fill.

D.2.6 do_wr {write data}
This command is used to enqueue a write cycle at the current address and page,
and with the size mask. If the previous enqueued command was a write, then
this command will continue from the previous write as a sequential cycle.
When the write cycle starts, the BTM will drive the 32-bit value of {write data}
on the bus. {write data} may include Z (tristate) and X (don't-care) bits.

D.2.7 do_fwr {write data}
This command behaves like do_wr, except that the CLF signal is asserted,
indicating to the system that the write cycle is a full write.

D.2.8 do_idle {number of cycles}
This command is used to enqueue an idle bus cycle. The parameter specifies
the number of idle cycles to be inserted. The minimum legal value is 1. If a
parameter of 0 is specified., the command will be ignored. The main use for
do_idle is to prevent two bus cycles from being merged into a sequential cycle.

D.2.9 do_swap {expected read data} {write data}
This command is used to enqueue a swap cycle. A swap cycle is a read cycle
followed by a write cycle; the CPU asserts lock during the whole sequence.

D.3 How It Works
Each time you type a command to the BTM, you are actually executing a
command file; when you type set_addr you are executing the command file
set_addr.cmd.
There are command files for each of the 10 commands recognized by the BTM.
The command files are divided into two groups:
•

Those prefixed with do_ advance the simulation clock (by a very small
amount).

•

Those prefixed with set_ do not advance the simulation clock.

D-4 SA-110 Bus Transactor Model User's Guide

SA-110 Bus Transactor Model User's Guide
0.3 How It Works
For example, the set_addr.cmd and do_crd.cmd files are shown below:
I I set_addr. cmd
I I usage example: set_addr 12345678\h

a sarm\sarm\cur_mem_a %1
11 end
I I do_crd. cmd
I I usage example: do_crd 12345678\h
I I does read in which elf is asserted. It is up to the user
I I to ensure that a legal combination of these commands is
I I strung together

a sarm\sarm\cur_mem_d %1
a sarm\sarm\cur_mem_op 00\b
a sarm\sarm\cur_mem_clf l\b
sim lOps
a sarm\sarm\write_mem_queue 1
defaults -time
sim lOps
a sarm\sarm\write_mem_queue 0
·a sarm\sarm\cur_mem_clf 0\b
defaults time
11 end

Within the BTM model there is a circular queue of commands. Each buffer entry
holds information for a single clock cycle (for example, do a read, from a certain
address, and expect certain data). All of the commands that are prefixed with
set_ simply deposit an argument onto ports within the model. The commands
that are prefixed with do_ toggle a port within the model that causes a new entry
(with appropriate values) to be enqueued. As the simulator clock is advanced,
commands are taken off the queue and used to produce bus transactions. When
the queue is empty, the BTM becomes idle.
The source code for the BTM is heavily commented and it should be possible to
understand it even of you are not familiar with VHDL.

D.4 It Is Not Idiot-Proof!
The BTM allows arbitrary transactions to be built up out of transaction 'atoms'.
As such, it allows you to model bus transactions that could not actually occur.
In particular, no address checks are done during sequential transactions. Some
illegal sequences are detected, and result in an error message and the forced
insertion of a stall cycle.
Here are some examples of illegal operations:
Example 1

set_addr 0
do_rd 0
set_addr 10000\h
do_rd 12345678\h
do_idle l\h

Here, the address sequence could never occur in a real sequential cycle. The BTM
will not detect or report the illegal sequence.

SA-110 Bus Transactor Model User's Guide D-5

SA-110 Bus Transactor Model User's Guide
D.4 It Is Not Idiot-Proof!
Example 2
set_addr 0
do_rd 0
set_addr 4
do_crd 12345678\h
do_idle l\h

Here, the sequential access started as a normal read, with CLF negated, but
continued as a cache line fill with CLF asserted. The BTM will not detect or
report the illegal sequence.
Example 3
set_addr' 0
do_crd 0
set_addr 4
do_crd 12345678\h
do_idle 1\h

Here, the sequential access was supposed to be a cache line fill, but it was only 2
beats long - a real cache-line fill would be 8 beats long. The BTM will not detect
or report the illegal sequence.
Example 4
set_addr 0
do_rd 0
set_addr 4
do_wr 12345678\h
do_idle 1\h

Here, an attempt has been made to perform a sequential access that is a write
for the first beat and a read for the second beat. This is the only type of illegal
sequence that the BTM will detect. In these circumstances, the BTM will report
an error and will force an idle cycle between the write and the read.

D.4.1 Completeness, Known Bugs and Model Support
The following signals are not modelled in the current version: pwrslp_l, tdi, td.o,
tms, ntrst, spdf, cccfg (but the value of cccfg is reported).
Refer to the header of the sarm.vhp file for an up-to-date list of implemented
functionality and known bugs.
If you discover a bug or omission in the BTM, please use the contact information
in the header of the sarm.vhp file to report it.

D.4.2 Porting, Modifying and Rebuilding
The BTM can be rebuilt by setting default to the behv/ subdirectory of the sarm_
model project area and typing 'make'.
The main source file for the BTM is called sarm.vhp. During the build process,
sarm.vhp is processed by the C preprocessor to generate sarm.vhd, which is used
as the input to the VHDL compiler. The BTM uses a number of routines from
pgk.vhp, which is preprocessed to generate pgk.vhd.
The BTM is written in VIEWlogic's VHDL, but should be portable to other
vendors' VHDL environment. For help with porting, refer to the contact
information in the header of the sarm. vhp file.

D-6 SA-110 Bus Transactor Model User's Guide

E
ABEL Tutorial
ABEL is a highly structured, industry standard PLD synthesis language. It
provides a powerful yet straightforward way to merge state machines with
random glue logic. There are tools available to take the high-level description
and split the functions into PLDs.
•

The AND function is represented by the ampersand(&), and the OR function
is represented by the pound sign(#).

•

There are two ways to assign an equation to an output. Using just an equal
sign (=) assigns a combinatorial output; using a colon followed by an equal
sign(:=) assigns a registered output. All registered outputs in this design are
edge triggered, clocked on the rising edge of cpu_mclk_l.

•

A comparison is done by using a double equal sign(==) for true and
an exclamation point and an equal sign (!=) for false. So, for example,
the equation (DEL_CREQ == READ_BLOCK) compares the signal set
DEL_CREQ with the constant value READ_BLOCK, and is considered true if
they are the same.

•

An equation or signal can be asserted low by adding an exclamation point
before it (!). An example of using the inversion operator:
DOE_L = SIGl # {SIG2 & !(SIG3 & SIG4));

The equation above inverts the (SIG3 & SIG4) equation before using it in the
rest of the right-hand side. The output signal DOE_L is just a name. The
fact that it ends with an "_L" does not invert it. That signal is still asserted
high. In order to cause the output to be asserted low, the inversion operator
(!) must precede the output signal, as follows:
!DOE_L = SIGl # (SIG2 & !(SIG3 & SIG4));
If the signal is an output pin for the ABEL partition, it can be inverted there
as well. Consider this code segment:
DECLARATIONS

!DOE_L
!ACK

PIN;
PIN;

EQUATIONS

DOE_L = SIGl # (SIG2 & !(SIG3 & SIG4));
ACK = 1;

The signals DOE_L, ACK are both used as asserted high signals inside the
ABEL file, and only inverted when sent out of the partition.
•

The state machine CASE dispatch method follows the general form of a
decision equation and a dispatch point, separated by a colon(:). There
are usually other signals associated with that dispatch, surrounded by
WITH/ENDWITH keywords. The WITHIENDWITH signals are treated

ABEL Tutorial E-1

ABEL Tutorial

slightly differently, depending upon whether they are edge triggered or
combinatorial.
•

An edge triggered signal (OUT := IN) surrounded by WITH/ENDWITH
and associated with a state dispatch asserts the signal on the next clock
edge, effectively changing with the state that is being dispatched to.

•

A combinatorial signal (OUT = IN) surrounded by WITH/ENDWITH
asserts during the current state. The signal is thus (hopefully) stable by
the next clock, to be used at the start of the next state.
As an example, consider this ABEL code segment:
STATE IDLE:
CASE
(DEL_CREQ == READ_BLOCK) : RDMEM_l
WITH
DOE_DIS := l;
MEM_RAS ::: l;
ENDWITH;
ENDCASE;

The delayed cReq lines are compared to the READ_BLOCK value, and if they
are the same the RDMEM_l state is dispatched to. The signal DOE_DIS is
asserted coincidentally with the start of RDMEM_l, and will not become true
until then. The signal MEM_RAS, on the other hand, will assert during the
IDLE cycle.

E-2 ABEL Tutorial

F
Getting Started with an Uncased Board
If your EBSA-110 has been supplied as an uncased board, use this section to help
you identify a suitable power supply and enclosure.

Before removing the board from its antistatic bag, read the handling precautions
in Section 1.2.
Use Appendix. A to help you attach the appropriate cables to the board, and
Section Al to help you to set the jumpers correctly.
Once you have fitted the EBSA-110 into an enclosure and wired it up, use the
checklist and power-on sequences described in Section 1.3.l and Section 1.4.

F.0.1 Choosing a Power Supply
The EBSA-110 requires +5V and +12V power (the power requirements are
described in Section 2.4).
Power is supplied to the EBSA-110 board by a 12-way connector which is
configured to be suitable for an industry-standard PC power supply. The other
signals provided by a PC power supply (DC_OK, -12V, -5V) are not used by the
EBSA-110 and are not connected on the board.
Refer to Section AS. l for information on how to identify the power connector and
align the power supply cable correctly.
Because of the very low current draw on the +12V power rail (only 30mA if no
PCMCIA card is fitted) ensure that the power supply has adequate low-load
regulation on the +12V power rail. Because PC-style power supplies are designed
to provide a high current on +12V, they may have poor low-load regulation. Use a
multimeter to verify that the off-load voltage of the +12V supply does not exceed
12.6V. If the low-load regulation is poor, add a dummy resistive load to the +12V
power rail. (An automobile light bulb provides a convenient load. Two bulbs in
parallel will provide redundancy in case one fails.)

F.0.2 Choosing an Enclosure
The EBSA-110 may be mounted in a standard PC enclosure. Any enclosure that
can accommodate a baby-AT format board will probably be suitable. If you intend
to use the PCMCIA sockets, you will probably need to modify the enclosure to
provide access. Choose an enclosure that makes modification easy.
The board has mounting holes which should align with mounting posts in
most enclosures. The mounting hole close to the Ethernet connector serves the
secondary purpose of providing a connection from the board OV to chassis ground.
Therefore, a conductive mounting bolt should be used in this position. All other
positions can use a plastic mounting clip. The conductive path is required for
proper operation of the Ethernet and should minimize electrical and magnetic
radiation. This connection does not affect the safety of the board (since the power
supply OV leads are also connected to chassis).

Getting Started with an Uncased Board F-1

Getting Started with an Uncased Board

If the EBSA-110 is used without an enclosure, it is advisable to put stand-offs in

the mounting holes. This will ensure that the bottom of the board is free from
the conductive detritus that inevitably accummulates on a laboratory bench. You
may also need to fit a wire link in position Ll. The bottom of the board contains
large copper planes for distributing +3.3V and +2V and you should be careful to
make sure that these do not short against anything.

F-2 Getting Started with an Uncased Board

G
Technical Support and Ordering Information
Obtaining Technical Support

If you need technical support or help deciding which literature best meets your

needs, call the Digital Semiconductor Information Line:
United States and Canada
Outside North America

1-800-332-2717
+1-508-628-4760

Ordering Digital Semiconductor Products

To order the following Digital Semiconductor products, contact your local
distributor.
To obtain a Digital Semiconductor Product Catalog, contact the Digital
Semiconductor Information Line.
Product

Order Number

SA-110 StrongARM microprocessor (100 MHz)

21281-BA

SA-110 StrongARM microprocessor (160 MHz)

21281-AA

SA-110 StrongARM microprocessor (200 MHz)

21281-CA

EBSA-110 Hardware Developer's Kit

QR-21A81-11
QR-21B81-01

ARM Software Developer's Kit - End User License
~~~~~~~~~~~~-

Note ~~~~~~~~~~~~-

The EBSA-110 is not available for sale; it is only available under a loan
agreement to qualified customers. Contact your Digital Semiconductor
distributor for further information.

Ordering Digital Semiconductor Literature

The following table lists some of the available Digital Semiconductor literature.
For a complete list, contact the Digital Semiconductor Information Line.
Title

Order Number

EBSA-110 Hardware Developer's Kit Read-Me-First

EC-QU9ZA-TE

Digital Semiconductor SA-110 Microprocessor Tools
Brochure

EC-QPWJB-TE

Digital Semiconductor SA-110 Microprocessor Product
Brief

EC-QPWKC-TE

Digital Semiconductor SA-110 Microprocessor Technical
Reference Manual

EC-QPWLB-TE

Technical Support and Ordering Information G-1

Index
A
ABEL tutorial, E-1
Address decoding
See Memory map
AIF, 8-2

Antistatic precautions, 1-1
Architectural compliance
overview, 2-6
test facilities, 3-7, 4-4
Architectural verification
test facilities, 3-7
Associated literature, G-1

B
bent, 10-15
Big-endian, 2-7
Binary notation, xii
8-bit accesses to odd addresses
Ethernet addresses, 3-11
hardware implementation, 10-18
PCMCIA addresses, 3-12
software techniques, 3-13
bootp utility, 9-4
Buffering, 10-7
Burst counter, 10-15

c
Cables
external to the box, A-10
within the box, A-9
Cabling, 1-3
CLKBY state machine, 10-13
Clocks, 10-4
CLKBY state machine, 10-13
ctb_clkby7, 3-9, 10-5, 10-11, 10-12, 10-13
mclk, 10-5
osc24, 10-5
overview, 2-1
SA-110 PLL, 10-4
setting the frequency, A-5
Configuration, A-1
clock frequency, A-5
default, A-1
links, A-5

Configuration (cont'd)
ofjumpers, A-1
Configuration of memory, 5-1
Configuration of memory space, 5-1
Configuration of VLSI devices, 5-1
Connection to host system, 1-4
Connectors
description, A-6
Control logic, 10-12
overview, 2-7
CPU
See SA-110
CTA, 10-12
See also control logic
CTB, 10-12
See also control logic
CTB_ARCH, 4-4
See also control logic
distinguishing from CTB_OS, 4-2
FIQ_CNT, 4-6
FIQ_MASK, 4-4
IRQ_CNT, 4-5
IRQ_MASK, 4-5
CTB_OS, 4-2
See also control logic
distinguishing from CTB_ARCH, 4-2
FIQ_MASK, 4-2
IRQ_MASK, 4-3
IRQ_MCLR, 4-3
IRQ_MSET, 4-3
IRQ_MSKD, 4--4
IRQ_RAW, 4-4

D
Debug, B-1
LED, 3-12
Debug support
connector pinouts, A-7
connectors, 10-6
LED, 1-4
overview, 2-7
pickup points, A-8
Decoupling, 10-3
Design database, C-1

lndex-1

Design improvements, 10-22
Diagnostics, 8-4
description of tests, 8-4
example output, 8-7
getting ready to run them, 8-4
Documentation, G-1
do_crd, D-4
do_fwr, D-4
do_idle, D-4
do_rd, D-4
do_swap, D-4
do_wr, D-4
DRAM
CBR (simulation), 11-24
configuration after reset, 5-1
configuration cycles, 10-19
configuration space decodes, 3-5
decodes, 3-4
disabling refresh, 5-2
enabling refresh, 5-3
interface, 10-7
overview, 2-5
refresh (simulation), 11-21
setting wrapping mode, 5-2
telling EDO from BEDO, 5-3
upgrading, A-13
waking up, 5-2
WCBR (simulation), 11-24
DRAM,BEDO
full write(simulation), 11-21
worst-case read (simulation), 11-14
worst-case write (simulation), 11-17
wrapped read (simulation), 11-19
DRAM,EDO
4-beat read (simulation), 11-10
4-beat write (simulation), 11-12
wrapped read (simulation), 11-14
DRAM state machine, 10-12

E
EBUFMEM space, 3-8
Eggs, 2-7
Enclosure
choosing a suitable, F-1
Endian, 2-7
EPROM
overview, 2-4
See also ROM, 2-4
startup, 8-3
Etch links, 10-6
Ethemet
buffer memory access, 3-8
buffer memory bandwidth, 6-4
cable, A-12
configuration, 5-7
control registers, 3-11
interface, 10-10

lndex-2

Ethernet (cont'd)
layout, 10-10
loading images, 9-4
Expansion
hints, 10-21
overview, 2-7

F
Flash
image header format, 8-2
organization, 8-2
overview, 2-4
programming: see FMU, 9-1
programming image into new system, 8-3
See also ROM, 2-4
sequential writes, 3-6
write (simulation), 11-30
FMU, 9-1
block-number parameter, 9-3
NoBoot option, 9-4

G
Gulliver's Travels, 2-7

H
Handling, 1-1
Hardware Developers Kit, C-1
HDK, C-1
Hexadecimal notation, xii
How it works, 10-1

I/O
read/write (simulation), 11-30
read/write with refresh (simulation), 11-34
stalled read/write (simulation), 11-34
trickbox read/write (simulation), 11-38
truncated read/write (simulation), 11-34
IJO Space
decodes, 3-6
I/O sub-system
overview, 2-5
Image selection, 8-1
Interrupts, 4--1
overview, 2-7
INTnn notation, xii
IO state machine, 10-13
ISAIO space, 3-8
PIT port-to-address conversion, 3-10
self-decoding, 3-9
ISAMEM Space, 3-7

J
JTAG
cable, A-12
overview, 2-7
port, 10-11
Jumpers, 10-6

L
LEDs
description, A-8
overview, 2-8
Literature, G-1
Little-endian, 2-7
Loadable debuggable images, 7-1

M
Main state ma.chine, 10-12
Manufacturers' data sheets, Xlll
Manufacturing bring-up process, 8-3
Memory
See also Performance
relative speeds, 3-4
See also DRAM, 2-4
See also EPROM, 2-4
See also Flash, 2-4
See also ROM, 2-4
See also SSRAM, 2-4
Memory map, 3-1
after reset, 3-3
decodes, 3-4, 10-19
switching, 3-3, 10-18
switching (simulation), 11-1
switching overview, 2-5

0
Ordering products, G-1

p
Packer address counter, 10-17
paka, 10-17
Parallel port
loopback connector, A-12
Parallel port cable, A-11
Parts
ordering, G-1
PBL, 8-1
PCMCIA
initialization, 5-4
interface, 10-11
memory access, 3-8
programming voltage, 5-5
setting a memory window, 5-5

PCMCIAMEM space, 3-8
PCMCIA registers, 3-12
Performance
impact of DRAM refresh, 6--3
of BEDO DRAM accesses, 6-2
ofEDO DRAM accesses, 6-1
of I/O accesses, 6-4
of overlapping cycles, 6-4
of SSRAM accesses, 6-1
overview, 6-1
ROM accesses, 6--3
Physical description, 1-1
PIT
configuration, 5-2, 5-3, 5-9
interface, 10-12
PIT registers, 3-9
Power, 10-3
Power sequencing
overview, 2-4
Power supply
choosing a suitable, F-1
connecting to board, A-9
overview, 2-3
+12V regulation, F-1
Principal buses, 10-2
Printed circuit board, 10-22
Programmers' guide, 3-1

R
Related documentation, G-1
Religious persecution, 2-7
Reset, 10-5
memory map after, 3-3
overview, 2-3
state after, 3-13
RFRSH state machine, 10-12
ROM
decodes, ~
interface, 10-8
multiple read (simulation), 11-28
overview, 2-4
single read (simulation), 11-26
RW_ABORT space, 3-7
R_ABORT space, 3-7

s
SA-110
bus cycles, 10-14
configuration options, 10-6
in socket, 1-3
overview, 2-1
types of bus cycle, 10-15
Semiconductor Information Line, G-1
Serial port cable, A-10
for SUN workstation, A-11

lndex-3

set_addr, D-3
set_masks, D-3
set_page, D-3
set_size, D-3
Simulation
bus transactor model, D-1
waveforms, 11-1
Soft register, 3-12
Software
overview, 2-8
Software development environment, 7-1
Speaker
connection, A-1
output, 3-12
SSRAM
decodes, 3-5
interface, 10-7
overview, 2-4
read sequences(simulation), 11-8
read wrapping (simulation), 11-6
worst-case read (simulation), 11-3
worst-case write (simulation), 11-3
Stall cycles, 6-1
Standalone Flash images, 7-2
Startup EPROM, 8-3
Sub-block wrapping, 10-15
Superl/O

lndex-4

configuration, 5-9
interface, 10-9
Superl/O registers, 3-10
Support services, G-1
Swift, J. L., 2-7

T
Technical support, G-1
Test points, 10-6
Tour of the schematics, 10-1

v
Visual Inspection, 1-1
Voltage domains
overview, 2-3
Voltage levels, 10-4

w
Wait states
See Stall cycles
Word
use of the term, xii
Wrapping, 10-15

.·..;.

····:.
}::_

Printed in U.S.A.