Zilog Z16C30 User Manual

Download

Z16C30

USC

User’s Manual

UM009402-0201

ZiLOG Worldwide Headquarters • 910 E. Hamilton Avenue • Campbell, CA 95008

Telephone: 408.558.8500 • Fax: 408.558.8300 • www.ZiLOG.com

Z16C30 USC

This publication is subject to replacement by a later edition. To determine whether a later edition exists, or to request copies of publications, contact:

ZiLOG Worldwide Headquarters

910 E. Hamilton Avenue Campbell, CA 95008 Telephone: 408.558.8500 Fax: 408.558.8300

www.ZiLOG.com

Document Disclaimer

ZiLOG is a registered trademark of ZiLOG Inc. in the United States and in other countries. All other products and/or service names mentioned herein may be trademarks of the companies with which they are associated.

©2001 by ZiLOG, Inc. All rights reserved. Information in this publication concerning the devices, applications, or technology described is intended to suggest possible uses and may be superseded. ZiLOG, INC. DOES NOT ASSUME LIABILITY FOR OR PROVIDE A REPRESENTATION OF ACCURACY OF THE INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED IN THIS DOCUMENT. ZiLOG ALSO DOES NOT ASSUME LIABILITY FOR INTELLECTUAL PROPERTY INFRINGEMENT RELATED IN ANY MANNER TO USE OF INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED HEREIN OR OTHERWISE. Except with the express written approval of ZiLOG, use of information, devices, or technology as critical components of life support systems is not authorized. No licenses are conveyed, implicitly or otherwise, by this document under any intellectual property rights.

UM009402-0201

ZILOG

UM009402-0201

Z16C30 USC® USER'S MANUAL

Thank you for your interest in Zilog's high-speed Integrated Universal Serial Controller.

To aid the designer, the following support material is available when designing

a High Performance Serial Communication application based on Zilog's USC.

Z16C30 User's Manual

Zilog's USC® User's Manual is a comprehensive breakdown of the functions and features of the USC which will aid in the development of your application. A good place to start is the manual, which provides a short description of each feature

Overview

section at the beginning of the

Z16C30 USC® USER'S MANUAL

SUPPLEMENTARY INFORMATION

and chapter. Then any chapter can be reviewed in more detail as necessary. This User's Manual provides in-depth descriptions of all functions and features of the USC as well as supporting block diagrams, timing diagrams, and sample applications.

Z16C30 Product Specification

The USC® Product Specification is a good resource to help determine which of Zilog's High Performance Serial Controllers to use. This document provides an in-depth description of the USC, including descriptions of features, block diagrams, pin assignments, pin descriptions, register bit functions, and AC and DC specifications. This

Application Notes

The following Application Notes are useful in demonstrating how the USC can be used in different applications.

Design a Serial Board to Handle Multiple Protocols

This Application Note details an approach to handling multiple serial communication protocols using Zilog's Z16C30 USC. This document is included in the High Speed SCC Databook, DC-8314-01 mentioned above.

Demonstration/Evaluation Boards

By selecting the board that most closely resembles your desired application, you may be able to use parts of the design in your implementation. These boards can be used as software platforms while the application hardware is being developed.

Z8018600ZCO - This kit contains an assembled circuit

board, software, and documentation to support the evaluation and development of code for Zilog's Z16C30 USC, Z16C32 IUSC, Z85C30 SCC, Z85230 ESCC, and Z16C35

specification can be found in the High Speed Serial Communication Controllers Databook, DC-8314-01, which also includes a product specification on the Z16C30 USC as well as related Application Notes, support products, and a list of third party support vendors.

The Zilog Datacom Family with the 80186 CPU

This Application Note, DC-2560-03, explains and illustrates how Zilog's datacom family interfaces and communicates with the 80186 on an evaluation board.

ISCC. The purpose of the board is to illustrate how the datacom family interfaces and communicates with the 80186 CPU. This will help potential customers evaluate Zilog's datacommunications with the 80186 CPU. A boardresident monitor program allows code to be downloaded and executed. A specification on this product is included in the High Speed Serial Communication Controllers Databook, DC-8314-01 mentioned above.

UM97USC0100

ZILOG

UM009402-0201

Demonstration/Evaluation Boards (Continued)

Z16C30 USC® USER'S MANUAL

SUPPLEMENTARY INFORMATION

Z16C3001ZCO - This kit contains an assembled PC/XT/AT

circuit board with two high-speed serial connections, DB9 and DB25 connectors selectively driven by RS-232 or RS422 line drivers.

The kit also contains software and documentation to support software and hardware development for Zilog's USC.

The board illustrates the use of Zilog's USC in communications applications such as ASYNC, SDLC/HDLC and highspeed ASYNC. (Please refer to the Product Specification Databook for a detailed description.)

© 1997 by Zilog, Inc. All rights reserved. No part of this document may be copied or reproduced in any form or by any means without the prior written consent of Zilog, Inc. The information in this document is subject to change without notice. Devices sold by Zilog, Inc. are covered by warranty and patent indemnification provisions appearing in Zilog, Inc. Terms and Conditions of Sale only. Zilog, Inc. makes no warranty, express, statutory, implied or by description, regarding the information set forth herein or regarding the freedom of the described devices from intellectual property infringement. Zilog, Inc. makes no warranty of merchantability or fitness for any purpose. Zilog, Inc. shall not be responsible for any errors that may appear in this document. Zilog, Inc. makes no commitment to update or keep current the information contained in this document.

Zilog’s products are not authorized for use as critical components in life support devices or systems unless a specific written agreement pertaining to such intended use is executed between the customer and Zilog prior to use. Life support devices or systems are those which are intended for surgical implantation into the body, or which sustains life whose failure to perform, when properly used in accordance with instructions for use provided in the labeling, can be reasonably expected to result in significant injury to the user.

Zilog, Inc. 210 East Hacienda Ave. Campbell, CA 95008-6600 Telephone (408) 370-8000 Telex 910-338-7621 FAX 408 370-8056 Internet: http://www.zilog.com

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC® USER'S MANUAL

TABLE OF CONTENTS

HAPTER TITLE AND SUBSECTIONS PAGE

Chapter 1 Introduction

1.1 Introduction ....................................................................................................... 1-1

1.2 Features............................................................................................................. 1-1

1.3 Logic Symbol..................................................................................................... 1-2

1.4 Packaging ......................................................................................................... 1-3

1.5 Overview of the USC and this Manual............................................................... 1-4

1.5.1 Bus Interfacing ....................................................................................... 1-4

1.5.2 Serial Interfacing..................................................................................... 1-4

1.5.3 Serial Modes and Protocols.................................................................... 1-4

1.5.4 DMA Operation ....................................................................................... 1-4

1.5.5 Interrupts ................................................................................................ 1-4

1.5.6 Software Summary.................................................................................. 1-4

1.6 Device Structure .............................................................................................. 1-12

1.6.1 The Transmit Data Path ........................................................................ 1-12

1.6.2 The Receive Data Path ......................................................................... 1-12

1.6.3 Clocking................................................................................................ 1-12

1.6.4 Interrupts .............................................................................................. 1-12

1.7 Document Structure ........................................................................................ 1-13

Z16C30 USC

USER'S MANUAL

Chapter 2 Bus Interfacing

2.1 Introduction ....................................................................................................... 2-1

2.2 Multiplexed/Non-Multiplexed Operation............................................................ 2-1

2.3 Read/Write Data Strobes ................................................................................... 2-3

2.4 Bus Width .......................................................................................................... 2-4

2.5 ACK vs. WAIT Handshaking.............................................................................. 2-4

2.6 Pin Descriptions ................................................................................................ 2-5

2.7 Pull-up Resistors and Unused Pins ................................................................... 2-7

2.8 The Bus Configuration Register (BCR).............................................................. 2-7

2.8.1 WAIT vs. Ready Selection ...................................................................... 2-7

2.8.2 Bits and Fields in the BCR ...................................................................... 2-7

2.9 Register Addressing.......................................................................................... 2-8

2.9.1 Implicit Data Register Addressing.......................................................... 2-8

2.9.2 Direct Register Addressing on AD13-AD8 ............................................. 2-8

2.9.3 Direct Register Addressing on AD6-AD0/7-1 ......................................... 2-9

2.9.4 Indirect Register Addressing in the CCAR ............................................. 2-9

2.9.5 About the Register Address Tables ..................................................... 2-10

2.9.6 Serial Data Registers TDR & RDR ........................................................ 2-14

2.9.7 Byte Ordering ....................................................................................... 2-14

2.9.8 Register Read & Write Cycles .............................................................. 2-14

UM97USC0100

ZILOG

UM009402-0201

CHAPTER TITLE AND SUBSECTIONS PAGE

Chapter 3 A Sample Introduction

3.1 Introduction ....................................................................................................... 3-1

Chapter 4 Serial Interfacing

4.1 Introduction ....................................................................................................... 4-1

4.2 Serial Interface Pin Descriptions ....................................................................... 4-1

4.3 Transmit and Receive Clocking ........................................................................ 4-2

4.3.1 CTR0 and CTR1...................................................................................... 4-2

4.3.2 The Baud Rate Generators ..................................................................... 4-2

4.3.3 Introduction to the DPLL ......................................................................... 4-5

4.3.4 TxCLK and RxCLK Selection .................................................................. 4-5

4.3.5 Clocking for Asynchronous Mode .......................................................... 4-6

4.3.6 Synchronous Clocking............................................................................ 4-6

4.3.7 Stopping the Clocks ............................................................................... 4-6

4.4 Data Formats and Encoding ............................................................................. 4-7

4.5 More About the DPLL ........................................................................................ 4-8

4.6 The RxD and TxD Pins .................................................................................... 4-10

4.7 Edge Detection and Interrupts ........................................................................ 4-11

4.8 The /DCD Pin ................................................................................................... 4-13

4.9 The /CTS Pin .................................................................................................... 4-15

4.10 The /RxC and /TxC Pins .................................................................................. 4-16

4.11 The /RxReq and /TxReq Pins .......................................................................... 4-17

4.12 The /RxACK and /TxACK Pins ......................................................................... 4-17

Z16C30 USC

USER'S MANUAL

Chapter 5 Serial Modes and Protocols

5.1 Introduction ....................................................................................................... 5-1

5.2 Asynchronous Modes........................................................................................ 5-1

5.3 Character Oriented Synchronous Modes.......................................................... 5-3

5.4 Bit Oriented Synchronous Modes ..................................................................... 5-4

5.5 The Mode Registers (CMR,TMR & RMR) .......................................................... 5-5

5.5.1 Enabling and Disabling the Receiver and Transmitter ........................... 5-7

5.5.2 Character Length.................................................................................... 5-7

5.5.3 Parity, CRC, Serial Encoding .................................................................. 5-8

5.6 Asynchronous Mode ......................................................................................... 5-9

5.6.1 Break Conditions .................................................................................. 5-10

5.7 Isochronous Mode........................................................................................... 5-10

5.8 Nine-Bit Mode.................................................................................................. 5-11

5.9 External Sync Mode ........................................................................................ 5-12

5.10 Monosync and Bisync Modes ......................................................................... 5-12

5.11 Transparent Bisync Mode ............................................................................... 5-14

5.12 Slaved Monosync Mode .................................................................................. 5-15

5.13 IEEE 802.3 (Ethernet) Mode ............................................................................ 5-16

5.14 HDLC/SDLC Mode .......................................................................................... 5-18

5.14.1 Received Address and Control Field Handling .................................... 5-18

5.14.2 Frame Length Residuals ....................................................................... 5-20

5.14.3 Handling a Received Abort .................................................................. 5-20

UM97USC0100

ZILOG

UM009402-0201

CHAPTER TITLE AND SUBSECTIONS PAGE

5.15 HDLC/SDLC Loop Mode ................................................................................. 5-21

5.16 Cyclic Redundancy Checking......................................................................... 5-22

5.17 Parity Checking ............................................................................................... 5-25

5.18 Status Reporting .............................................................................................. 5-26

5.18.1 Detailed Status in the TCSR ................................................................. 5-28

5.18.2 Detailed Status in the RCSR ................................................................. 5-29

5.19 DMA Support Features .................................................................................... 5-31

5.19.1 The Character Counters ....................................................................... 5-31

5.19.2 The RCC FIFO ...................................................................................... 5-35

5.19.3 Transmit Control Blocks ........................................................................ 5-36

5.19.4 Receive Status Blocks .......................................................................... 5-38

5.19.5 Finding the End of a Received Frame .................................................. 5-39

5.20 Commands ...................................................................................................... 5-40

5.21 Resetting a USC Channel................................................................................ 5-44

5.22 The Data Registers and the FIFO's ................................................................. 5-45

5.22.1 Accessing the TDR & RDR ................................................................... 5-45

5.22.2 TxFIFO and RxFIFO Operation ............................................................. 5-45

5.22.3 Fill Levels .............................................................................................. 5-46

5.22.4 DMA & Interrupt Request Levels .......................................................... 5-46

5.23 Handling Overruns & Underruns ..................................................................... 5-47

5.23.1 Tx Underruns ........................................................................................ 5-47

5.23.2 Rx Overruns .......................................................................................... 5-47

5.23.3 Rx Overrun Scribbling .......................................................................... 5-48

5.23.4 Fill Level Correctness & Extra Bytes..................................................... 5-48

5.24 Between Frames, Messages, or Characters ................................................... 5-49

5.24.1 Synchronous Transmission ................................................................... 5-49

5.24.2 Async Transmission .............................................................................. 5-49

5.24.3 Synchronous Reception ....................................................................... 5-51

5.25 Synchronizing Frames/Messages with Software Response............................ 5-51

Z16C30 USC

USER'S MANUAL

Chapter 6 Direct Memory Access (DMA) Interfacing

6.1 Introduction ....................................................................................................... 6-1

6.2 Flyby vs. Flowthrough DMA Operation.............................................................. 6-1

6.3 DMA Requests by the Receiver & Transmitter .................................................. 6-6

6.3.1 Programming the DMA Request Levels ................................................. 6-7

6.4 DMA Acknowledge Signals ............................................................................... 6-8

6.5 Separating Received Frames in Memory .......................................................... 6-8

UM97USC0100

iii

ZILOG

UM009402-0201

CHAPTER TITLE AND SUBSECTIONS PAGE

Chapter 7 Interrupts

7.1 Introduction ....................................................................................................... 7-1

7.2 Interrupt Acknowledge Daisy-Chains................................................................ 7-1

7.3 External Interrupt Control Logic ........................................................................ 7-2

7.4 Using /RxReq and /TxReq as Interrupt Requests ............................................. 7-3

7.5 Interrupt Types & Sources................................................................................. 7-4

7.6 Internal Interrupt Operation ............................................................................... 7-6

7.7 Details of the Model........................................................................................... 7-8

7.8 Interrupt Option in the BCR ............................................................................... 7-9

7.9 Interrupt Acknowledge Cycles .......................................................................... 7-9

7.10 Interrupt Acknowledge vs. Read Cycles ......................................................... 7-14

7.11 Interrupt Types ................................................................................................ 7-14

7.11.1 Receive Status Interrupt Sources and IA Bits ...................................... 7-14

7.11.2 Receive Data Interrupts ........................................................................ 7-15

7.11.3 Transmit Status Interrupt Sources and IA Bits...................................... 7-18

7.11.4 Transmit Data Interrupts ....................................................................... 7-19

7.11.5 I/O Pin Interrupt Sources and IA Bits .................................................... 7-20

7.11.6 Miscellaneous Interrupt Sources and IA Bits ....................................... 7-20

7.12 Interrupt Pending and Under Service Bits ...................................................... 7-21

7.13 Interrupt Enable Bits ........................................................................................ 7-22

7.14 Channel Interrupt Options ............................................................................... 7-22

7.15 Interrupt Vectors .............................................................................................. 7-23

7.16 Software Requirements ................................................................................... 7-24

7.16.1 Nested Interrupts .................................................................................. 7-24

7.16.2 Which Type(s) to Handle? .................................................................... 7-24

7.16.3 Handling a Type ................................................................................... 7-25

7.16.4 Exiting the ISR ...................................................................................... 7-27

Z16C30 USC

USER'S MANUAL

Chapter 8 Software Summary

8.1 Introduction ....................................................................................................... 8-1

8.2 About Resetting ................................................................................................. 8-1

8.3 Programming Order .......................................................................................... 8-2

8.4 Using DMA to Initialize a Channel ..................................................................... 8-2

8.5 Determining the Device Revision Level............................................................. 8-3

8.6 Tips & Techniques............................................................................................. 8-3

8.6.1 Common Hardware Problems ................................................................ 8-3

8.6.2 Common Software Problems .................................................................. 8-3

8.7 Test Modes ........................................................................................................ 8-6

8.8 Register Reference.......................................................................................... 8-10

8.8.1 Register Addresses .............................................................................. 8-10

8.8.2 Conditions/Context ............................................................................... 8-10

8.8.3 Description ........................................................................................... 8-10

8.8.4 RW Status ............................................................................................. 8-10

UM97USC0100

ZILOG

UM009402-0201

CHAPTER TITLE AND SUBSECTIONS PAGE

Appendix A Appendix Changes

A.1 Introduction ............................................................................................................ A-1

A.1.1 Transmit Status Blocks/Transmit Control Blocks .................................... A-1

A.1.2 Interrupt Enable (for Individual Sources) Interrupt Arm ......................... A-1

A.2 Commands ........................................................................................................ A-1

A.2.1 Reload RCC/TCC

Load RCC/TCC ....................................................................................... A-1

A.2.2 Select Straight/Swapped Memory ..........................................................A-1

A.2.3 Preset CRC Clear Tx/Rx CRC Generator................................................ A-1

A.3 Bit/Field Names ................................................................................................. A-1

Appendix B

Questions and Answers ...............................................................................................B-1

Z16C30 USC

USER'S MANUAL

UM97USC0100

ZILOG

UM009402-0201

FIGURE TITLES PAGE

Chapter 1

Figure 1-1. USC Logic Symbol ................................................................................. 1-2

Figure 1-2. USC 68-pin PLCC Pinout ........................................................................ 1-3

Figure 1-3. USC Block Diagram.............................................................................. 1-11

Chapter 2

Figure 2-1. Simple Multiplexed System .................................................................... 2-1

Figure 2-2. Simple Interface to Non-Multiplexed Bus ............................................... 2-2

Figure 2-3. User-Friendly Interface to Non-Multiplexed Bus .................................... 2-2

Figure 2-4. /RD & /WR Signaling ............................................................................... 2-3

Figure 2-5. R//W and /DS Signaling .......................................................................... 2-3

Figure 2-6. A Fast and Slow Cycle with Three Kinds of Handshaking ..................... 2-5

Figure 2-7. The USC's Bus Configuration Register (BCR) ........................................ 2-7

Figure 2-8. The Channel Command/Address Register (CCAR) ............................. 2-10

Figure 2-9. USC Register Addressing .................................................................... 2-11

Figure 2-10. A Register Read Cycle with Multiplexed Addresses and Data ............ 2-15

Figure 2-11. A Register Write Cycle with Multiplexed Addresses and Data ............ 2-16

Figure 2-12. A Register Read Cycle with Non-Multiplexed Data Lines .................... 2-17

Figure 2-13. A Register Write Cycle with Non-Multiplexed Data Lines..................... 2-18

Z16C30 USC

USER'S MANUAL

Chapter 3

Figure 3-1. Sample Application ................................................................................ 3-2

Figure 3-2. Serial Interface for Sample Application .................................................. 3-3

Chapter 4

Figure 4-1. A Model of a USC Channel's Clocking Logic ......................................... 4-3

Figure 4-2. The Clock Mode Control Register (CMCR) ............................................ 4-4

Figure 4-3. The Hardware Configuration Register (HCR) ......................................... 4-4

Figure 4-4. Data Formats/Encoding .......................................................................... 4-7

Figure 4-5. The Channel Command/Status Register (CCSR) ................................... 4-9

Figure 4-6. The Input/Output Control Register (IOCR) ........................................... 4-10

Figure 4-7. The Status Interrupt Control Register (SICR)........................................ 4-12

Figure 4-8. The Miscellaneous Interrupt Status Register (MISR) ............................ 4-12

Figure 4-9. /DCD Auto-Enable Timing .................................................................... 4-14

Figure 4-10. /CTS Auto-Enable Timing ..................................................................... 4-15

UM97USC0100

ZILOG

UM009402-0201

FIGURE TITLES PAGE

Chapter 5

Figure 5-1. Asynchronous Data ................................................................................ 5-2

Figure 5-2. Character Oriented Synchronous Data .................................................. 5-2

Figure 5-3. HDLC/SDLC Data ................................................................................... 5-4

Figure 5-4. The Channel Mode Register (CMR) ....................................................... 5-6

Figure 5-5. The Transmit Mode Register (TMR)........................................................ 5-6

Figure 5-6. The Receive Mode Register (RMR) ........................................................ 5-6

Figure 5-7. Carrier Detection for a Received Ethernet Frame ................................ 5-16

Figure 5-8. The Channel Command/Status Register (CCSR) ................................. 5-21

Figure 5-9. A Model of the Receive Datapath......................................................... 5-24

Figure 5-10. How a USC Channel Provides the "Queued" Status Bits in the RCSR. 5-27

Figure 5-11. The Transmit Command/Status Register (TCSR) ................................. 5-28

Figure 5-12. The Receive Command/Status Register (RCSR).................................. 5-29

Figure 5-13. A Model of the Transmit Character Counter Feature............................ 5-33

Figure 5-14. A Model of the Receive Character Counter Feature ............................ 5-34

Figure 5-15. The Channel Command/Status Register (CCSR) ................................. 5-37

Figure 5-16. The Channel Control Register (CCR) ................................................... 5-37

Figure 5-17. A 32-Bit Transmit Control Block in a DMA Buffer ................................. 5-37

Figure 5-18. A 32-Bit Receive Status Block in a DMA Buffer.................................... 5-38

Figure 5-19. The Channel Command/Address Register (CCAR) ............................. 5-41

Z16C30 USC

USER'S MANUAL

Chapter 6

Figure 6-1. Flowthrough DMA Transfer Memory to Peripheral Device ..................... 6-2

Figure 6-2. Flowthrough DMA Transfer, Peripheral Device to Memory .................... 6-3

Figure 6-3. Flyby DMA Transfer, Memory to Peripheral Device ............................... 6-4

Figure 6-4. *Flyby DMA Transfer, Peripheral Device to Memory .............................. 6-5

UM97USC0100

vii

ZILOG

UM009402-0201

FIGURE TITLES PAGE

Chapter 7

Figure 7-1. An Interrupt Daisy Chain ........................................................................ 7-2

Figure 7-2. External Interrupt Control........................................................................ 7-3

Figure 7-3. USC Interrupt Types & Sources ............................................................. 7-5

Figure 7-4. A Model of the Interrupt Logic for Source "s" and type "t" ...................... 7-7

Figure 7-5. An Interrupt Acknowledge Cycle Signaled by /SITACK, .............................

on a Multiplexed Bus ............................................................................ 7-10

Figure 7-6. An Interrupt Acknowledge Cycle Signaled by /SITACK, .............................

on a Non-Multiplexed Bus .................................................................... 7-11

Figure 7-7. A /PITACK Interrupt Acknowledge Cycle with 2PulseIACK=0 ............. 7-12

Figure 7-8. A /PITACK Interrupt Acknowledge Cycle with 2PulseIACK=1 ............. 7-13

Figure 7-9. The Receive Command/Status Register (RCSR).................................. 7-15

Figure 7-10. The Receive Interrupt Control Register (RICR) .................................... 7-15

Figure 7-11. A Sample Service Routine for Receive Data Interrupts........................ 7-17

Figure 7-12. The Transmit Command/Status Register (TCSR) ................................. 7-18

Figure 7-13. The Transmit Interrupt Control Register (TICR) .................................... 7-18

Figure 7-14. The Status Interrupt Control Register (SICR)........................................ 7-19

Figure 7-15. The Miscellaneous Interrupt Status Register (MISR)............................ 7-19

Figure 7-16. The Daisy-Chain Control Register (DCCR)........................................... 7-22

Figure 7-17. The Interrupt Control Register (ICR)..................................................... 7-22

Figure 7-18. The Interrupt Vector Register (IVR) ...................................................... 7-24

Z16C30 USC

USER'S MANUAL

Chapter 8

Figure 8-1. Test Mode Data Register with TMCR 4-0=00101 (Clock Mux Outputs) ... 8-7

Figure 8-2. Test Mode Data Register with TMCR 4-0=00111 (Clock Mux Inputs)...... 8-8

Figure 8-3. Test Mode Data Register with TMCR 4-0=01110 (I/O and Misc Status) .. 8-9

viii

UM97USC0100

ZILOG

UM009402-0201

TABLE TITLES PAGE

Chapter 1

Table 1-1. Bus Interfacing Features of the USC ...................................................... 1-5

Table 1-2. Serial Interfacing Features of the USC ................................................... 1-6

Table 1-3. Serial Controller Features of the USC ..................................................... 1-7

Table 1-4. More Serial Controller Features of the USC............................................ 1-8

Table 1-5. DMA Features of the USC ...................................................................... 1-9

Table 1-6. Interrupt Features of the USC ............................................................... 1-10

Chapter 2

Table 2-1. USC Registers, in Address Order ........................................................ 2-12

Table 2-2. USC Registers, in Alphabetical Order .................................................. 2-13

Z16C30 USC

USER'S MANUAL

UM97USC0100

Zilog, Inc. 210 East Hacienda Ave. Campbell, CA 95008-6600 Telephone (408) 370-8000 Telex 910-338-7621 FAX 408 370-8056 Internet: http://www.zilog.com

ZILOG

UM009402-0201

1.1 INTRODUCTION

SER

’s M

ANUAL

CHAPTER 1

INTRODUCTION

Z16C30 USC

USER'S MANUAL

The Universal Serial Controller (USC®) is the next-generation successor to Zilog’s popular SCC family of multiprotocol serial controllers, and is recommended for new designs. Compared to the SCC family and most competing devices, the USC features more serial protocols, a 16or 8-bit data bus, higher data rates, larger FIFOs, better support for DMA operation, and more convenient software

1.2 FEATURES

■ Two Full-Duplex Multi-Protocol Serial Controllers

■ Supports External DMA Channels with two Request

and two Acknowledge Lines

■ Serial Data Rates to 10 Mbits/Second

■ 32-Character Transmit and Receive FIFOs for each

Channel

■ 8- or 16-Bit Transfers for both Serial Data and

Registers

handling. The USC can handle higher data rates because it takes its timing reference from the software-selected receive and transmit clocks and the host bus control signals, rather than from a separate “bus clock” or “master clock”.

■ Async Features Include False-Start Filtering, Stop Bit

Length Programmable by 1/16-bit steps, Parity Generation/Checking, Break Generation/Detection

■ HDLC/SDLC Features Include 8-Bit Address Checking,

Extended Address Support, 16/32 bit CRC, Programmable Idle State, Auto Preamble Option, Loop Mode

■ Sync Features Include 2 to 16-Bit Sync Pattern, Sync

Strip Option, 16/32-bit CRC, Programmable Idle State, Auto Preamble Option, X.21 XMIT/RCV Slaving

■ Flexible Adaptation to Various System Buses

■ Serial Modes Include Asynchronous, Bisync, SDLC,

HDLC, Ethernet, and Nine-Bit

■ Two Baud Rate Generators per Channel

■ Digital Phase Locked Loop for each Channel

■ Carrier Detect, Clear to Send, and Two Serial Clock

pins for each Channel

■ Transmit and Receive Frame-Length Counters for

each Channel

UM97USC0100

■ Improved Bus/Serial Interlocks Prevent extra Rx DMA

Characters and Ensure Correct FIFO Fill Level Reporting

■ Flexible Interrupt Modes Including Interrupt

Acknowledge Daisy Chain

■ High-Speed, Low Power CMOS Technology

■ 68-Pin PLCC

1-1

ZILOG

UM009402-0201

1.3 LOGIC SYMBOL

VDD

Z16C30 USC

USER'S MANUAL

/RESET

/CS

A//B

D//C

/AS

R//W

/DS /RD

/WR /SITACK /PITACK

IEIA, B

/RxACKA,B

/TxACKA,B

/RxCA,B

/TxCA,B

RxDA,B

/CTSA,B

/DCDA,B

Figure 1-1. USC Logic Symbol

Z16C30

USC

VSS

AD15-AD0

/WAIT//RDY /INTA,B IEOA,B

/RxREQA,B /TxREQA,B

/TxDA,B

1-2

UM97USC0100

ZILOG

UM009402-0201

1.4 PACKAGING

/TxACKA

/WAIT//RDY

/SITACK6A//B5D//C4/CS3/RESET

VDD

68 67

VDD

/AS

/DS

/RD

/W/R

/PITACK61/TxACKB

R//W

Z16C30 USC

USER'S MANUAL

/RxACKA

/INTA

IEIA

IEOA

VSS VDD

AD0

AD1

AD2

AD3

AD4

AD5 AD6 AD7 VSS

VDD

/RxREQA

10 11 12 13 14 15 16 17

Z16C30 USC

18 19 20 21 22 23 24 25 26

27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

(Top View)

60 59

58 57 56 55 54 53 52 51 50 49 48 47 46 45 44

/RxACKB

/INTB

IEIB

/IEOB VSS

VDD AD8 AD9 AD10 AD11

AD12 AD13

AD14 AD15 VSS VDD /RxREQB

UM97USC0100

/RxCA

/TxREQA

VSS

RxDA

/DCDA

Figure 1-2. USC® 68-Pin PLCC Pinout

TxDA

/TxCA

/CTSA

VSS

TxDB

/CTSB

/TxCB

/DCDB

RxDB

/RxCB

/TxREQB

1-3

ZILOG

UM009402-0201

1.5 OVERVIEW OF THE USC AND THIS MANUAL

Z16C30 USC

USER'S MANUAL

The following descriptions and Tables should be helpful in initial evaluation of the USC® and in finding your way around this document. Subjects in the Tables are arranged in the same order they are covered in Chapters 2 and 4-8.

1.5.1 Bus Interfacing

Chapter 2 describes interfacing the USC to a processor or backplane bus. The USC includes several flexible interfacing options as described in Table 1-1. Some of these options are controlled by the Bus Configuration Register (BCR), which is implicitly the destination of the first write to the USC after a Reset, and is then no longer accessible to software.

1.5.2 Serial Interfacing

Chapter 4 covers Serial Interfacing, the “other side” of hardware design from Bus Interfacing. Table 1-2 summarizes the Serial Interfacing features of the USC, which include Clock Selection, Baud Rate Generation, serial data Encoding and Decoding, a Digital Phase Locked Loop for reconstructing clocking from received data, and “modem control” pins.

1.5.3 Serial Modes and Protocols

Chapter 5 covers how to program the Transmitter and Receiver to handle many different protocols and applica-

tions. This Chapter focuses on software aspects of using the USC while Chapter 4 is more hardware-oriented. Tables 1-3 and 1-4 show the major subjects that you can find in Chapter 5.

1.5.4 DMA Operation

Chapter 6 describes how to use the USC with DMA channels, and is outlined in Table 1-5.

1.5.5 Interrupts

While Chapters 4-6 mention which conditions and events can be enabled/armed to interrupt the processor, Chapter 7 pulls together all aspects of the USC’s extensive interrupt capabilities, including interrupt acknowledge cycles, vectors, and use of Interrupt Under Service bits to implement nested interrupts. Table 1-6 summarizes the subject.

1.5.6 Software Summary

Chapter 8 contains only a small amount of new material: a few software-related matters that didn’t seem to fit in anywhere else. The bulk of the Chapter is the Register Reference tables that summarize the use and function of each bit and field in each register in the USC.

1-4

UM97USC0100

Z16C30 USC

UM009402-0201

ZILOG

Table 1-1 Bus Interfacing Features of the USC (Chapter 2) Multiplexed or Separate Address and Data Bus(es) can be selected for processor access to USC registers. Read/Write Control Signals Separate Read and Write strobes, or Data strobe and Direction

control can be used. Only one set of signals should be connected to the host processor; the other should be pulled up.

8- or 16-Bit Data Bus DMA efficiency and bandwidth are doubled by using a 16-bit

bus, and software size and tediousness is improved as well. With an 8-bit data bus and non-multiplexed Address and Data, the bus pins that would otherwise be unused can be used for register addressing from the processor.

Ready, Wait, or Acknowledge Handshaking can be selected for processor cycles. If Wait signalling is

selected, the USC drives Wait for interrupt acknowledge cycles but not for register accesses — its 60 nanosecond register access time is fast enough for no-Wait operation in almost all applications. If Acknowledge signaling is selected, the part drives the Acknowledge line for both interrupt acknowledge cycles and register accesses.

USER'S MANUAL

Interrupt Acknowledge Cycles Separate inputs are provided for “Status line” vs. “pulse”

signalling. In the latter case single-pulse or double-pulse cycles can be selected. The USC can also be used on buses that don’t include Interrupt Acknowledge cycles.

Direct or Indirect Register Addressing The board designer can conserve the address space occu-

pied by the USC by requiring software to write register addresses into the USC, or can maximize software efficiency by presenting register addresses directly. On a non-multiplexed 16-bit data bus, the latter choice requires external components/logic to multiplex the low-order bits of the address onto the AD pins.

Registers There are 32 16-bit registers in each channel of the USC,

including three selectable subregisters in the MSbyte of two of them.

Big- or Little-Ending Byte Ordering Motorola or Intel style addressing can be selected for serial

data. Byte addressing within the USC’s 16-bit registers is inherently Little-Endian/Intel style.

UM97USC0100

1-5

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

1.5.6 Software Summary (Continued)

Table 1-2. Serial Interfacing Features of the USC (Chapter 4)

Clock Selection Clocking for the Transmitter and Receiver can come from the

/RxC or /TxC pins, and can be used directly or can be divided by 4, 8, 16, or 32 by Counters 0 and 1, and/or by any value from 1 to 65,536 by Baud Rate Generators 0 and 1. Or, clocking can come from the Digital Phase Locked Loop (DPLL) module, which tracks transitions on the RxD pin.

Clock Output Clocking can also be driven out on the /TxC or /RxC pin for use by on-

board logic, a modem or other interface.

CTR0, CTR1 These two 5-bit free-running counters can each divide /RxC or /TxC by

4, 8, 16, or 32. They can provide the Transmit or Receive bit clocks directly, or can act as “prescalers” for the Baud Rate Generators.

Baud Rate Generators BRG0 and BRG1 are 16-bit counters, each of which can divide /RxC,

/TxC, or the output of CTR0 or CTR1 by any value from 1 to 65,536. They can source the Transmit or Receive bit clocks, act as the reference clock for the DPLL, or can be used as timers on either a polled or interrupt-driven basis. They can be stopped and started by software, and can run continuously or stop when they reach zero. Their period (time constant) values can be reprogrammed dynamically, effective immediately or when the BRG counts down to zero.

Digital-Phase Locked Loop The DPLL can divide /RxC, /TxC, or the output of BRG0 or BRG1 by 8,

16, or 32, while resynchronizing to transitions on RxD, to recover a Receive clock from the Receive data signal. This can be done only when the received data stream includes enough transitions to keep the recovered clock synchronized to the data. NRZI-Space encoding of HDLC/SDLC frames, or Biphase (FM) encoding with any protocol, guarantees such data transitions.

Data Encoding The USC can encode transmitted data and decode received data in

NRZI-Mark, NRZI-Space, Biphase-Mark (FM1), Biphase-Space (FM0), Biphase-Level (Manchester), or Differential-Biphase-Level modes. These encodings are used in various applications to maintain synchronization between transmitting and receiving equipment.

Echoing and Looping Received data can be repeated onto TxD, or transmit data can be

looped back to the Receiver for testing.

Modem Controls and Interrupts Carrier Detect and Clear to Send inputs can auto-enable the

Receiver and Transmitter, respectively. Rising and/or falling edges on these pins can cause interrupts, as can edges on the Transmit and Receive Clock pins (if they’re not used for clocking), and/or the Transmit and Receive Request pins if they’re not used for DMA requests.

DMA Controller Interface Each channel of the USC provides Tx and Rx Request outputs for

connection to a DMA controller, and Tx and Rx Acknowledge inputs for “flyby” (single-cycle) DMA operation. The Acknowledge pins can be used for other purposes if “flowthrough” (two-cycle) DMA controller is employed. Both Request and Acknowledge pins can be used for other purposes if no DMA controller is used.

1-6

UM97USC0100

Z16C30 USC

UM009402-0201

ZILOG

USER'S MANUAL

Table 1-3. Serial Controller Features of the USC

Major Protocol Categories Chapter 4 begins with a small tutorial on the differences between Asynchronous,

Character-Oriented Synchronous, and Bit-Oriented Synchronous (Packet) protocols.

Asynchronous Protocols In addition to classic Async, the USC can handle the following variations:

■ Isochronous (1X rather than 16-64X clock)

■ Nine-Bit (Address Wake-up — an extra bit signifies Address/Data)

Character-Oriented Synchronous Protocols ■ External Sync (Receive only: simple character assembly)

■ Monosync (1-character sync pattern, no hardware framing)

■ Bisync (2-character sync pattern, no hardware framing)

■ Transparent Bisync (Bisync + hardware support for Transparency)

■ Slaved Monosync (Xmit only; X.21 Tx character alignment to Rx)

■ IEEE 802.3 (Ethernet; requires external collision detect and backoff)

Bit-Oriented Synchronous Protocols ■ HDLC/SDLC

■ HDLC/SDLC Loop (RxD is repeated on TxD except when Xmit is

enabled and triggered by a received Go Ahead/Abort sequence)

Character Length is programmable from 1 bit/character to:

■ 8 bits including Parity, if any, in synchronous modes

■ 8 bits plus Parity, if any, in Async mode

■ 8 bits plus Parity plus the Address/Data bit in Nine-Bit mode

CRC Generation/Checking In synchronous modes, the USC will generate and check CRC-CCITT, CRC-16, or

CRC-32 codes for each frame or message. For character-oriented modes other than 802.3, software can selectively control which characters are included in the CRC, for both transmitting and reception. For HDLC/SDLC and 802.3, CRC status can be stored in memory for each received frame.

Parity Checking Asynchronous or Synchronous modes. Odd/Even/Mark/Space/None. Transmit Status Reporting Optional interrupt on: Preamble Sent, Idle Sent, Abort Sent, End of Frame/

Message, CRC Sent, Underrun No interrupt: All Sent, Tx Empty

Receive Status Reporting Optional Interrupt on: Exited Hunt, Idle Received, Break, Abort (immediate or

synchronized with the RxFIFO), Rx Boundary (end of frame/message), Parity Error, Overrun. No interrupt: Short Frame, Code Violation Type, CRC Error, Framing Error, Rx Character Available

Character Counters These 16-bit counters decrement for each character received or fetched from

memory for transmission. The Tx CC can control the length of Tx frames in synchronous modes using DMA. The Rx CC tracks the length of each Rx frame in synchronous modes using DMA, and optionally interrupts in case an Rx frame is too long.

RCC FIFO A four-deep store for ending Rx Character Counter values for each frame.

UM97USC0100

1-7

ZILOG

UM009402-0201

USER'S MANUAL

Table 1-4. More Serial Controller Features of the USC

Transmit Control Blocks A Transmit DMA channel can fetch the Tx CC frame length and other control info

for each frame/message, before the frame in the memory buffer.

Receive Status Blocks The Rx DMA channel can provide the frame status (including CRC status) for

each frame/message after the frame. Optionally it can also provide the the Rx CC frame length residual, although this is only useful in Rx DMA applications in which software can read the number of bytes/words that were stored, from the DMA channel.

Commands Software can write various command codes to 3 different register fields in each

channel, to control the operation of the channel. Commands can be divided into those that select a long-term configuration of a channel (like selecting which serial character in a 16-bit word comes first), those that make the part perform a time-sequenced action (like sending an Abort sequence), and those that change the state of the part immediately (like purging a FIFO).

Software Reset Software can reset a USC channel by writing a central register bit, similarly to

a hardware-signaled Reset.

Rx and Tx FIFO Storage 32-character FIFOs stand between the Transmit Data Register and the Trans-

mitter, and between the Receiver and the Rx Data Register. Fill level counters track how many characters are in each FIFO, and independently programmable threshold values determine when DMA operation will be triggered to fill or empty them, and/or when an interrupt will be requested.

Z16C30 USC

Between Frames/Messages In synchronous modes the Transmitter will do the following before the first

data character of each frame or message, and/or after the last one:

■ optionally send a 8-to 64-bit Preamble for PLL synchronization or mini-

mum inter-frame timing

■ send an "opening" sync sequence or Flag

■ After the last character from memory, sending the CRC accumulated by the

USC is optional. Thus, a CRC received with a frame can be sent back out without being regenerated.

■ send a "closing" Flag or Sync

■ send a selected "idle" pattern unless/until the next frame is ready to be sent

Waiting for Software Response Software can select 3 optional interlocks between frames, to allow it to do

real-time processing on a frame-by-frame basis.

1-8

UM97USC0100

Z16C30 USC

UM009402-0201

ZILOG

Table 1-5. DMA Features of the USC

Flowthrough or Flyby The USC can be used with DMA controllers in a “flowthrough” mode,

in which the REQ line from the USC tells the DMAC when to transfer data by means of separate accesses to the USC and to memory. Alternatively, the USC and DMA can operate in a “flyby” mode, in which there’s also an ACK line from the DMAC to tell the USC when to drive data to the memory or when to capture data from the memory. Flyby operation requires only one bus cycle per (pair of) character(s).

DMA Requests A USC can provide separate Transmit and Receive DMA Request

outputs from each of its two channels, that become active when the relevant FIFO reaches a software-selected level of emptiness or fullness, and stay active until the FIFO is filled or emptied. The Receive Request for a channel operating in a synchronous block oriented mode (e.g., HDLC) will also go active when the end of a message or frame is received.

Separating Receive Frames Chapter 5 ends with a description of how the “Wait for Rx Trigger”

feature can be used to separate received frames into individual memory buffers, by withholding the Rx DMA Request for the data in a new frame until after software has read out the length of the frame and/ or programmed the DMA channel with the buffer address for the new frame.

USER'S MANUAL

UM97USC0100

1-9

ZILOG

UM009402-0201

Table 1-6. Interrupt Features of the USC

Interrupt Acknowledge Daisy Chaining was one of Zilog’s original contributions to microprocessor architecture. On the USC

its use (to determine which of several interrupting devices to service first) is optional, and performance is much improved compared to older devices.

External Interrupt Control can be used instead of a daisy chain to implement interrupt priority schemes other

than strict priority, such as “fairness”, rotating, or first-come first-served.

Types of interrupts that can be selectively enabled or disabled include Receive Status,

Receive Data, Transmit Status, Transmit Data, I/O Pin, and Miscellaneous.

Receive Status Interrupt sources that can be selectively armed or disarmed include Exited Hunt, Idle

Received, Break, Abort (immediate and/or synchronized to received data), End of Frame/Message, Parity Error, and RxFIFO Overrun.

Receive Data Interrupt can occur when the RxFIFO reaches a programmed level of fullness. Transmit Status Interrupt sources that can be selectively armed or disarmed include Preamble Sent, Idle

Sent, Abort Sent, End of Frame/Message Sent, CRC Sent, and Tx Underrun.

Transmit Data Interrupt can occur when the TxFIFO reaches a programmed level of emptiness.

Z16C30 USC

USER'S MANUAL

I/O Pin Interrupt sources that can be selectively armed or disarmed include rising and/or falling

edges on the /DCD, /CTS, /RxREQ, /TxREQ, /RxC, and /TxC pins.

Miscellaneous Interrupt sources that can be selectively armed or disarmed include Rx Character Counter

Underflow, DPLL Sync Loss, Baud Rate Generator 0 zero, and BRG1=0.

Nested Interrupts are fully supported in that the USC includes an Interrupt Pending and Interrupt

Under Service bit for each type of interrupt.

Interrupt Acknowledge Cycles The USC is compatible with a wide variety of processors in that the signal that

identifies an acknowledge cycle can be sampled like an address bit, or can carry a single or double pulse similar to a read or write strobe.

Interrupt Vectors The USC can include identification of the highest priority requesting type of interrupt

in the vector that it returns during an interrupt acknowledge cycle.

Non-Acknowledging Buses Software can simulate the effects of interrupt acknowledge cycles if the USC is used

on a bus that doesn’t provide such cycles, like the ISA (AT) bus.

1-10

UM97USC0100

ZILOG

UM009402-0201

Transmitter

DPLL

Counters

BRG0, BRG1

Serial Clock

Logic

Receiver

Z16C30 USC

USER'S MANUAL

Host

Processor

DMA

Controller,

System

Memory

Bus

Interface

Transmit

FIFO

Transmit

FIFO

Transmitter

Interrupt

Control

Interrupt

Control

Serial Clock

Logic DPLL

Counters

BRG0, BRG1

Receive

FIFO

Channel A

16-Bit Internal

Data Bus

Channel B

Receive

FIFO

Receiver

UM97USC0100

Figure 1-3. USC® Block Diagram

1-11

ZILOG

UM009402-0201

1.6 DEVICE STRUCTURE

Z16C30 USC

USER'S MANUAL

Figure 1-1 shows the basic structure of the USC. The Bus Interface module stands between the external bus pins and an on-chip 16-bit data bus that interconnects the other functional modules. It includes several flexible bus interfacing options that are controlled by the Bus Configuration Register (BCR). The BCR is automatically the destination of the first write cycle from the host processor to the USC after a Reset. After that it is no longer accessible to the host software.

1.6.1 The Transmit Data Path

Either the host processor or an external DMA channel can write transmit data into a channel’s Transmit First-In, FirstOut (FIFO) memory. At any time, a Transmit FIFO can be empty or can contain from 1 to 32 characters to be transmitted. Characters written into the TxFIFO become available to the Transmitter in the order in which they were written.

While the host processor can itself write data into the Transmit FIFOs, it’s more efficient to use external Transmit DMA channels to fetch the data. The host can program a USC channel so that its Transmitter will trigger its DMA controller to fill its FIFO at varying degrees of FIFO “emptiness”. Selecting this point involves balancing the probability and consequences of “underrunning” the transmitter, against the overhead for the DMA channel to acquire control of the host bus more often.

have to detect and synchronize start bits, check parity and stop bits, calculate and check CRCs, detect flag, abort and idle sequences, recognize control characters including transparency considerations, decode the serial data and clock extraction using any of several encoding schemes, and/or enable and disable reception based on the DCD input pin. The Receivers’ checking functions generate several status bits associated with each character, that accompany the characters through the Receive FIFOs.

The Receive FIFOs can hold up to 32 characters and their associated status bits. As the receivers write entries into their FIFOs, the entries become available to either the host processor or external Receive DMA channels. As on the transmit side, the Receive FIFOs include detection logic for various degrees of “fullness”. Separate thresholds control the point at which a channel starts requesting its DMA channel starts to refill its FIFO, and at which a channel requests an interrupt. Besides the main Receive FIFOs, each channel has a 4-entry RCC FIFO that can hold values indicating the length of up to four received frames.

While the host processor can access data from the Receive FIFOs, it’s more efficient to use external Receive DMA channels to transfer the data directly into buffer areas in memory. The USC can provide the status (and optionally the RCC value at the end) of each frame in the serial data stream, after the last character of the frame.

The serial Transmitters take characters from the Transmit FIFOs and convert them to serial data on the TxD pins. While this function is conceptually simple, the USC supports many complex serial protocols, which increases the complexity of the Transmitters dramatically. Depending on the serial mode selected, the Transmitters may do any of the following in addition to parallel-serial conversion: start, stop, and parity bit generation, calculating and sending CRCs, automatic generation of opening and closing flags, encoding the serial data into any of several formats that guarantee transitions and carry clocking with the data, and/or controlling transmission based on the CTS pin.

1.6.2 The Receive Data Path

In general, the functions of the Receivers are the inverse of those of the Transmitters: they monitor the serial data on the RxD pin, organize it according to the serial mode selected by the software, and convert the data to parallel characters that they place in the Receive FIFOs. Again, there is more to the process than just serial-parallel conversion. Depending on the serial mode the Receivers may

1.6.3 Clocking

Each channel includes a Serial Clocking Logic section that creates the clocking signals for the channel’s Transmitter and Receiver. Software can program the clocking logic to do this in various ways based on one or two external clock(s) for each channel. Each channel also includes a Digital Phase Locked Loop (DPLL) circuit that can recover clocking from encoded data on RxD.

1.6.4 Interrupts

There’s also an Interrupt Control section in each channel, that gathers the various “request” lines from the Transmitter and Receiver, and takes care of requesting host interrupts and responding to host interrupt-acknowledge cycles or to software equivalents. Interrupt operation depends on the data written to the Bus Configuration Register and on several registers in the Receiver and Transmitter. There are a separate set of interrupt pins for each channel so that external logic can control their relative priority.

1-12

UM97USC0100

ZILOG

UM009402-0201

1.7 DOCUMENT STRUCTURE

Z16C30 USC

USER'S MANUAL

The Chapters in this manual attempt to provide the firsttime reader with a staged and gradual introduction to the USC. The manual is structured according to the USC’s major internal blocks and various aspects of their operation, rather than as a list and description of each of its registers. The various registers and fields are covered in conjunction with the facilities that they report on and control. Chapter 8 then reviews the general programming model and includes a concise description of each register bit and field for quick reference.

The actual timing parameters and electrical specifications of the IUSC are given in the companion publication 'USC Product Specification'.

We at Zilog hope that this newly structured manual will make the USC more easily understandable and accessible. Naturally, it’s impossible to write at the right level for all readers; newcomers will find some parts hard going, while experts will undoubtedly tire of full explanations of matters that “everyone knows”. Our target audience is neither newcomers nor experts, but midway between: working engineers with some datacom background.

UM97USC0100

Zilog, Inc. 210 East Hacienda Ave. Campbell, CA 95008-6600 Telephone (408) 370-8000 Telex 910-338-7621 FAX 408 370-8056 Internet: http://www.zilog.com

1-13

ZILOG

UM009402-0201

2.1 INTRODUCTION

SER

’s M

ANUAL

CHAPTER 2

BUS INTERFACING

Z16C30 USC

USER'S MANUAL

The USC® can be used in systems with various microprocessor or backplane buses. Its flexibility with respect to host bus interfacing derives from its Bus Configuration Register (BCR), from on-chip logic that monitors bus

activity before software writes the BCR, and from certain other registers in the serial channels. This section describes how to use these facilities to interface the USC to a variety of host microprocessors and buses.

2.2 MULTIPLEXED/NON-MULTIPLEXED OPERATION

One important distinction among buses is whether they include separate sets of lines for addresses and for data, or whether the same set of lines carries multiplexed addresses and data. On a multiplexed bus, the USC captures addressing at rising edges on /AS. If this signaling is the

same as that used on the host bus (as with a Zilog 16C0x), then the USC’s /AS pin can be directly connected to the corresponding bus signal. Figure 2-1 shows such a system.

AD15:AD0

/AS

16C01

UM97USC0100

AD15:AD0

/AS

USC

Figure 2-1. Simple Multiplexed System

2-1

ZILOG

UM009402-0201

2.2 MULTIPLEXED/NON-MULTIPLEXED OPERATION (Continued)

Z16C30 USC

USER'S MANUAL

An 80x86-based system differs only in that the processor’s ALE signal has to be inverted to produce /AS for the USC.

Figures 2-2 and 2-3 illustrate two ways to interface the USC to a non-multiplexed host bus. Figure 2-2 includes minimum hardware but requires that software write the register address into the USC each time it is going to access a register. In this mode the USC’s /AS pin should be pulled up to ensure a constant high logic level. Figure 2-3 includes drivers to sequence the low-order bits of the host address onto the USC’s AD lines, and logic to synthesize a pulse on the /AS pin. This interfacing method has the advantage that software can directly address the USC’s registers.

The USC monitors the /AS pin from the time the /RESET pin goes high until the software writes the Bus Configuration Register. If it sees /AS go low at any point in this period, then after the software writes the BCR, the USC captures the state of the low-order AD lines, A//B, C//D, and /CS, at each rising edge of /AS. If /AS remains high, software may have to write each register address into the Channel Command/ Address Register (CCAR) before reading or writing a register. (If the host bus only includes 8 data lines, AD13-AD8 can carry register addresses.)

D15:D0

A15-A0 D15-D0

Cntrl Signals

Control

Logic

/AS

USC

Figure 2-3. User-Friendly Interface to

/RD, /WR

AD15-AD0

Non-Multiplexed Bus

/AS

68000

AD15:AD0

VCC

/AS

USC

Figure 2-2. Simple Interface to Non-Multiplexed Bus

2-2

UM97USC0100

ZILOG

Read Operation:

Write Operation:

R//W

DS*

R//W

Data Bus (Slave)

Data Bus

DS*

UM009402-0201

2.3 READ/WRITE DATA STROBES

Another difference among host buses is the way in which read and write cycles are signalled and differentiated. Figures 2-4 and 2-5 show two standard methods supported by the USC. In Figure 2-4, the bus includes separate strobe lines for read and write cycles, commonly called /RD and /WR. In Figure 2-5, the bus includes a data strobe line, /DS, that goes low for both read and write cycles, and a R//W line that differentiates read cycles from writes. The USC includes pins for all four of these signals. The two that match up with host bus signals should be connected to those signals. The two unused pins should be pulled up to a high level.

Read Operation:

RD*

WR*

Z16C30 USC

USER'S MANUAL

Write Operation:

Data Bus

RD*

WR*

Data Bus

Figure 2-4. /RD and /WR Signaling

Figure 2-5. R//W and /DS Signaling

There is no programmable option for the distinction between /RD-/WR and R//W-/DS operation. The USC simply responds to either pair of lines, which is why it’s important to pull up the unused pair. Also, the USC doesn’t demand that the R//W line remain valid throughout the assertion of /DS. It captures the state of R//W at the leading/falling edge of /DS, so that R//W need only satisfy setup and hold times with respect to this edge.

Only one among the bus signals /DS, /RD, /WR, and /PITACK may be active at a time. This prohibition also

includes /RxACKA, /RxACKB, /TxACKA, and /TxACKB when these pins are used as DMA acknowledge signals. (Chapter 5 covers DMA interfacing including the “ACK” signals, and Chapter 6 describes the USC’s interrupt features including /PITACK). If the USC detects more than one of these inputs active simultaneously, it enters an inactive state from which the only escape is via the /RESET pin.

UM97USC0100

2-3

ZILOG

UM009402-0201

2.4 BUS WIDTH

Z16C30 USC

USER'S MANUAL

Another major difference among host buses is the number of data bits that can be transferred in one cycle. Software can configure the USC to transfer 16 bits at a time, in which case it is still possible to transfer 8 bits when this is necessary or desirable. Or, software can restrict operation to transferring only 8 bits at a time, on the AD7-AD0 pins.

2.5 ACK VS. WAIT HANDSHAKING

The final major difference among host buses involves the nature of the handshaking signals that slave devices use for speed-matching with masters. Figure 2-6 illustrates the three variations in common use. In the first, which we’ll call Wait signaling, if a master selects a slave and the slave cannot capture write data or provide read data within the time allowed to keep the master operating at full speed, it quickly (combinatorially) drives a Wait output low, and then returns it to high when it’s ready to complete the cycle. Some peripheral devices have Wait outputs that are opencollector or open-drain, which can be tied together for a negative logic wired-Or function. Because the USC drives its /WAIT//RDY output high or low on a full-time basis, a logic gate must be used to negative-logic OR (positivelogic AND) its /WAIT//RDY output with the /WAIT signal(s) for other slaves, to produce the /WAIT input to the master (e.g., to the processor).

In the second scheme, “Acknowledge” signaling, all slaves must respond when the master directs a cycle to them, by driving an Acknowledge signal (sometimes called /DTACK) low to allow the master to complete the transfer, and keeping it low until the master does so. As with the previous scheme, some peripherals provide slave Ack outputs that are open-collector or open-drain, which can be tied together for a negative logic wired-Or function. Because the USC drives its /WAIT//RDY output high or low on a full-time basis, a logic gate must be used to negative-logic OR its /WAIT//RDY output with the /ACK signals for other slaves, to produce the Acknowledge input to the master.

This leaves the AD15-AD8 pins unused: another BCR option allows them to carry register addresses. The latter option allows software to directly address USC registers even on a non-multiplexed bus, without having to write an address into the USC before it accesses a register.

In the third scheme, “Ready” signaling, all slaves must respond when the master directs a cycle to them, by driving a Ready signal high to allow the master to complete the transfer, and keeping it high until the master does so. This scheme differ from Wait signaling in the default state of the handshaking signal between cycles (high for Wait signaling, low for Ready). It has similar timing as Ack signaling, but differs in the polarity of the handshaking signal. With Ready signaling, the board designer must include a logic gate to positive-logic OR the various slaves’ Ready lines to produce a composite Ready input for the bus master(s).

The USC supports Acknowledge and Ready signaling for all cycles, and Wait signaling for interrupt acknowledge cycles. The USC register access times should be short enough to avoid the need for Wait signaling on all but the fastest processors. The board designer can combine the USC’s /WAIT//RDY output with similar signals from other slaves, by means of an external logic gate or (for Acknowledge and Wait) an external tri-state or open-collector driver.

If software writes the Bus Configuration Register (BCR) at an address that makes the A//B pin low, the USC drives /WAIT//RDY low as an “Acknowledge” signal, while if software writes the BCR with A//B high, the USC drives /WAIT//RDY as a “wait” signal.

2-4

UM97USC0100

ZILOG

UM009402-0201

RD* or WR*

or DS*

WAIT*

ACK*

Ready

Figure 2-6. A Fast and Slow Cycle, with Three Kinds of Handshaking

2.6 PIN DESCRIPTIONS

Z16C30 USC

USER'S MANUAL

/RESET. Reset (input, active low). A low on this line places

the USC in a known, inactive state, and conditions it so that the data, from the next write operation that asserts the /CS pin, goes into the Bus Configuration Register (BCR) regardless of register addressing. /RESET should be driven low as soon as possible during power-up, and as needed when restarting the overall system or the communications subsystem.

AD15-AD0. Address/Data Bus (inputs/tri-state outputs). These lines carry data between the controlling microprocessor and the USC, and may also carry multiplexed addresses of registers within the USC. If the USC is used with an external DMA controller, these lines also carry data between the USC and system memory or the DMA controller. AD15-AD0 can be used in a variety of ways based on whether the USC senses activity on /AS after Reset, and on the data written to the Bus Configuration Register (BCR).

/CS. Chip Select (input, active low). A low on this line indicates that the controlling microprocessor’s current bus cycle refers to a register in the USC. The USC ignores /CS when a low on /SITACK or /PITACK indicates that the current bus operation is an interrupt acknowledge cycle. On a multiplexed bus the USC latches the state of this pin at rising edges on /AS, while on a non-multiplexed bus it latches /CS at leading/falling edges on /DS, /RD, or /WR.

A//B. Channel Select (input, high indicates “channel A”). Cycles with /CS low, and /SITACK, /PITACK, and this pin both high, access registers for channel A. Cycles with /SITACK and /PITACK high, and /CS and this pin both low, access registers for channel B. The state of this line when the Bus Configuration Register is written determines “wait

vs. acknowledge” operation, as described later in this chapter. On a multiplexed bus the USC latches the state of this pin at rising edges on /AS, while on a non-multiplexed bus it latches the state at leading/falling edges on /DS, /RD, or /WR.

D//C. Data/Control (input, high indicates Data). A read cycle with /CS low, and /SITACK, /PITACK, and this pin high, fetches data from the receive FIFO of the channel selected by A//B, via its Receive Data Register (RDR). A write cycle with the same conditions writes data into that channel’s transmit FIFO via its Transmit Data Register (TDR). Cycles with /SITACK and /PITACK high and both /CS and this pin low read or write a USC register. On a multiplexed bus the USC determines which register to access from the low-order AD lines at the rising edge of /AS. On a non-multiplexed bus it typically selects the register based on the LSBits of the serial controller’s Channel Command/Address Register. On a multiplexed bus the USC latches the state of this pin at rising edges on /AS, while on a non-multiplexed bus it latches the state at leading/falling edges on /DS, /RD, or /WR.

/AS. Address Strobe (input, active low). After a reset, the USC’s bus interface logic monitors this signal to see if the host bus multiplexes address and data on AD15-AD0. If the logic sees activity on /AS before (or as) software writes the Bus Configuration Register, then in subsequent cycles directed to the USC, it captures register selection from the AD lines, A//B, and D//C on rising edges of /AS.

For a non-multiplexed bus this pin should be pulled up to +5V. If a processor uses a non-multiplexed bus, yet has an output called Address Strobe (e.g., 680x0 devices), this pin should not be tied to the output.

UM97USC0100

2-5

ZILOG

UM009402-0201

2.6 PIN DESCRIPTIONS (Continued)

Z16C30 USC

USER'S MANUAL

R//W. Read/Write control (input, low signifies “write”).

R//W and /DS indicate read and write cycles on the bus, for host processors/buses having this kind of signaling. The USC samples R//W at each leading/falling edge on /DS.

/DS. Data Strobe (input, active low). R//W and /DS indicate read and write cycles on the bus, for host processors/ buses having this kind of signaling. It is qualified by /CS low or /SITACK low. The USC samples R//W at each leading/ falling edge on this line. For write cycles, the USC captures data at the rising (trailing) edge on this line. In read cycles the USC provides valid data on the AD lines within the specified access time after this line goes low, and this data remains valid until after the master drives this line back to high.

/RD. Read Strobe (input, active low). This line indicates a read cycle on the bus, for host processors/buses having this kind of signaling. It is qualified by /CS low or /SITACK low. In Read cycles the USC provides valid data on the AD lines within the specified access time after this line goes low, and this data remains valid until after the master drives this line back to high.

/WR. Write Strobe (input, active low). This line indicates write cycles on the bus, for host processors/buses having this kind of signaling. It is qualified by /CS low. The USC captures write data at the rising (trailing) edge of this line.

Only one of /DS, /RD, /WR, or /PITACK may be driven low in each bus cycle. This restriction also includes

/TxACK and/or /RxACK if they’re used as “flyby” DMA Acknowledge signals.

/WAIT//RDY. Wait, Ready, or Acknowledge handshaking (output, active low). This line can carry “wait” or “acknowledge” signaling depending on the state of the A//B input during the initial BCR write. If A//B is high when the BCR is written, this line operates thereafter as a Ready/Wait line for Zilog and some Intel processors. In this mode the USC asserts this line low until it’s ready to complete an interrupt acknowledge cycle, but it never asserts this line when the host accesses one of the USC registers.

If A//B is low when the BCR is written, this line operates thereafter as an Acknowledge line for Motorola and some Intel processors. In this mode the USC asserts this line low for register read and write cycles, and also when it is ready to complete an interrupt acknowledge cycle.

/INTA,B. Interrupt Requests (outputs, active low). A channel drives its /INT pin low when (1) its IEI pin is high, (2) one or more of its interrupt type(s) is (are) enabled and pending, and (3) the Interrupt Under Service flag isn’t set for its highest priority enabled/pending type, nor for any higherpriority type within the channel. The USC drives these pins high or low at all times — they are neither tri-state nor opendrain pins.

/SITACK, /PITACK. Interrupt Acknowledge (inputs, active low). A low on one of these lines indicates that the host processor is performing an interrupt acknowledge cycle. In some systems a low on one of these lines may further indicate that external logic has selected this USC as the device to be acknowledged, or as a potential device to be acknowledged. The two signals differ in that /SITACK should be used for a level-sensitive “status” signal that the USC should sample at the leading edge of /AS or /DS, while /PITACK should be used for a single-pulse or double-pulse protocol. The other, unused pin should be pulled up to a high level. A channel will respond to an interrupt acknowledge cycle in a variety of ways depending on its /INT and IEI lines, as described in Chapter 7.

IEIA,B. Interrupt Enable In (inputs, active high). These signals and the IEO pins can be part of an interruptacknowledge daisy-chain with other devices that may request interrupts. If a channel’s IEI pin is high outside of an interrupt acknowledge cycle, and one or more interrupt type (s) is (are) enabled and pending for that channel, and the Interrupt Under Service flag isn’t set for the (highest priority such) type nor for any higher-priority type within the channel, then the channel requests an interrupt by driving its /INT pin low. If a channel’s IEI pin is high during an IACK cycle, one or more interrupt type(s) is (are) enabled and pending in that channel, and the Interrupt Under Service flag isn’t set for the (highest priority such) type nor for any higher-priority one within the channel, then the channel forces its IEO line low and responds to the cycle.

IEOA,B. Interrupt Enable Out (outputs, active high). These signals and the IEI pins can be part of an interrupt acknowledge daisy chain with other devices that may request interrupts. A channel drives its IEO pin low whenever its IEI pin is low, and/or whenever the Interrupt Under Service flag is set for any type of interrupt within the channel. These signals operate slightly differently during an interrupt acknowledge cycle, in that a channel also forces its IEO pin low if it is (has been) requesting an interrupt.

In any case this is a full time (totem pole) output. The board designer can combine this signal with similar signals for other slaves, by means of an external logic gate or a tri-state or open-collector driver.

2-6

VCC, VSS. Power and Ground. The inclusion of seven pins for each power rail insures good signal integrity, prevents transients on outputs, and improves noise margins on inputs. The USC’s internal power distribution network requires that all these pins be connected appropriately.

UM97USC0100

ZILOG

UM009402-0201

2.7 PULL-UP RESISTORS AND UNUSED PINS

Z16C30 USC

USER'S MANUAL

All unused input pins should be pulled up, either by connecting them directly to Vcc or with a resistor. This may include /PITACK, /SITACK, IEI, and /ABORT.

Bi-directional pins should typically be pulled up with a resistor of about 10K ohms, to allow the USC to drive them as outputs. This may include /TxREQ, /RxREQ, /TxC, /RxC, /CTS, and /DCD.

Tri-state output pins may need to be pulled up to protect external logic from the effects of having a floating input. Again, a resistor of about 10K ohms is recommended. This may include /TxREQ, /RxREQ, TxD, and /INT.

2.8 THE BUS CONFIGURATION REGISTER (BCR)

The BCR is a 16-bit register having the format shown in Figure 2-7. All the bits in the BCR reset to zero. Software's first access to the USC™ after a hardware reset, must be a write to the BCR. If the host processor handles 16-bit data, and the data bus between it and the USC is at least 16 bits wide, then the software’s initial access to the USC should be a 16-bit write. This write can be to any address that activates the /CS pin; the data will be placed in the BCR. If the host can only write bytes to the USC, all data should be transferred on the AD7-AD0 pins. In such a system, pull-down resistors should be attached to the AD15-AD8 pins to ensure the state of these lines during the BCR write. (AD15 may want to be pulled up instead of down, as described in the section on the SepAd bit below.)

2.8.1 Wait vs. Ready Selection

The USC captures the state of the A//B pin when the software writes the BCR. It uses this captured state after the BCR write, such that if A//B was low, it drives the /WAIT //RDY pin as an “acknowledge” (or inverted “ready”) signal during register accesses and interrupt acknowledge cycles, while if A//B was high, it drives the pin as a “wait” signal during interrupt acknowledge cycles only. Therefore, software should program the BCR at an address that corresponds to the kind of slave-to-master handshaking used on the host bus.

2.8.2 Bits and Fields in the BCR

SepAd (Separate Address; BCR15): this bit should only be

written as 1 with 16-bit=0. This combination conditions the USC to use AD7-AD0 for data and to take register addressing from AD13-AD8. In this mode the USC takes the Upper/ Lower byte indication (U//L) from AD8 and the register address from AD13-AD9

With this interfacing technique, the BCR must be written at an address such that AD13-AD8 are low/zero. Further, AD15 must be high/one and AD14 must be low/zero when software writes the BCR. The designer can ensure this by connecting AD15 and AD14 to more-significant address lines and writing the BCR at an appropriate address. Alternatively, the designer can ensure this by connecting a pull-up resistor to AD15 and a pulldown resistor to AD14.

This mode is useful with a non-multiplexed bus, to avoid making the software write a register address to CCAR before each register access. In this mode the USC captures the state of AD13-AD8 on each leading/falling edge on /DS, /RD, or /WR. But software can still program SepAd=1 (with 16-bit=0) when the USC has detected early activity on /AS. In this case the USC captures addressing from AD13-AD8 on each rising edge of /AS, rather than from the low-order AD lines as would be true with SepAd=0.

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

UM97USC0100

ReservedSepAd 16-Bit

Figure 2-7. The USC’s Bus Configuration Register (BCR)

2Pulse

IACK

SRight

2-7

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

2.8.2 Bits and Fields in the BCR (Continued)

16-Bit (BCR2): this bit should be written as 1 when the host

data bus is 16 bits wide (or wider). Writing this bit as 0 has two effects: it restricts the host to using byte transfers on AD7-AD0 when reading and writing the USC’s registers, and it makes the USC ignore the state of the “B//W” signal or bit for register accesses. This bit also controls whether “implicit” accesses to the CCAR, TDR, and RDR are 8 or 16-bit wide.

2PulseIACK (Double-Pulse Interrupt Acknowledge; BCR1): software should program this bit to 0 if the /PITACK pin isn’t used or if it carries a single pulse when the host processor acknowledges an interrupt, or to 1 if /PITACK carries two pulses when the host processor acknowledges an interrupt. (The latter mode is compatible with certain Intel processors.)

SRightA (Shift Right Addresses; BCR0): this bit is significant only for a multiplexed bus — the USC ignores it for a non-multiplexed bus. If SRightA is 1, the USC captures register addressing from the AD6-AD0 pins and ignores the AD7 pin. In this mode, AD0 carries the Upper/Lower

byte indication (U//L), AD5-AD1 carry the actual register address, and AD6 carries the Byte/Word indication (B//W). If SRightA is 0, the USC captures addressing from AD7AD1 and ignores AD0. It takes U//L from AD1, the register address from AD6-AD2, and B//W from AD7. This bit has no effect on the use of the S//D and D//C pins.

SRightA would be 0 when using the USC as an 8-bit peripheral on a 16-bit bus, which isn’t likely to be a common application. Some sections of this manual assume that SRightA is 1.

All other bits in the BCR are reserved and should be programmed as 0. If the processor can only write bytes to the USC, software can only write the 8 LSBits of the BCR, on the AD7-AD0 lines. In this case, the state of AD15-AD8, when software writes the BCR, must be ensured by connecting these pins to pulldown resistors, or, if SepAd=1, to host address lines.

2.9 REGISTER ADDRESSING

The flowchart of Figure 2-9 shows how the USC determines which register to access when a host processor cycle asserts /CS and one of /RD, /WR, or /DS.

In all register accesses, the A//B pin selects between the two serial channels in the USC. The USC samples A//B, and other pins as described below, at the rising/trailing edge of /AS, or, if /AS is pulled up so that it’s always High, at the falling/leading edge of /DS, /RD, or /WR.

2.9.1 Implicit Data Register Addressing

If the USC samples the D//C pin high, a write operation accesses the Transmit Data Register (TDR) and a read operation selects the Receive Data Register (RDR). The access is implicitly 16 bits wide if the 16-bit bit in the Bus Configuration Register (BCR2) is 1 (indicating a 16-bit data bus) or 8 bits wide if BCR2 is 0.

This means that, on a 16-bit bus, software can neither write a byte to the TDR/TxFIFO nor read a byte from the RDR/RxFIFO using an address that makes D//C high. Instead, software must provide the explicit address of the LS byte of the TDR/RDR, either directly or by writing it to the CCAR.

2.9.2 Direct Register Addressing on AD13-AD8

If the USC samples D//C low, and the SepAd bit in the Bus Configuration Register (BCR15) is 1 (which should only be the case with an 8-bit data bus) the USC samples the AD13-AD9 pins as a RegAd to select which register to access, and samples AD8 as U//L to select which byte of the register to access. The USC always interprets a U//L bit in the “little-Endian” fashion, with a 1 indicating the moresignificant 8 bits of the register.

If the USC samples AD13-AD8 as all zero in this mode, indicating the Channel Command/Address Register (CCAR), the USC uses the contents of the CCAR to select which register to access, as described in ‘Indirect Register Addressing’ below.

2-8

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

2.9.3 Direct Register Addressing on AD6-AD0/AD7-AD1

If the USC samples D//C low, SepAd (BCR15) is 0, and the USC detected activity on /AS before or as the BCR was written, the USC samples the low-order AD pins to determine which register to access. It takes the register selection (RegAd) from AD5-1 if SRightA (BCR0) is 1, or from AD6-AD2 if SRightA is 0. If 16-bit (BCR2) is 1, the USC samples AD6 (or AD7 if SRightA/BCR0 is 0) as B//W to determine whether to access all 16 bits if the register (if B/ /W is 0) or just 8. If 16-bit is 0 or B//W is 1, it samples AD0 (or AD1 if SRightA is 0) as U//L to select which byte of the register to access. The USC always interprets a U//L bit in the “little-Endian” fashion, with a 1 indicating the moresignificant 8 bits of the register. U//L should be 0 for all 16bit accesses.

If the USC samples AD6-0 (or 7-1 if SRightA is 1) as all zero in this mode, indicating the Channel Command/Address Register (CCAR), the USC uses the contents of the CCAR to select which register to access, as described in the next section.

2.9.4 Indirect Register Addressing in the CCAR

If the USC samples D//C low, and:

1. SepAd (BCR15) is 1 and the USC samples AD13-AD8

as all zero indicating the CCAR, or

2. SepAd is 0, the USC detected activity on /AS before or

as the BCR was written, and it samples AD6-AD0 as all zero indicating the CCAR, or

3. SepAd is 0 and the USC did not detect activity on /AS

before nor as the BCR was written,

then it uses the less-significant byte of the CCAR to select which register to access.

Figure 2-8 shows the CCAR. When the USC takes indirect register addressing from it, the RegAd field (CCAR5-1) selects which register to access. If 16-bit (BCR2) is 1, the USC uses CCAR6 as B//W to determine whether to access all 16 bits of the register (if B//W is 0) or just 8. If 16-bit is 0 or B//W is 1, it uses CCAR0 as U//L to select which byte of the register to access.

Whenever it uses CCAR as an indirect address, the USC thereafter clears CCAR6-0 to zero, so that the next access to CCAR address again references all 16 bits of the CCAR itself. Thus, after writing a register address to the CCAR, reading or writing the CCAR address accesses the register selected by the address written, but another write to the CCAR address thereafter again writes an address into the CCAR.

CCAR can always be used to select a register for a subsequent access to the CCAR address, even if the USC detected activity on /AS after Reset, and regardless of the state of SepAd (BCR15).

Typically when software uses indirect register addressing, the CCAR address is the only one it reads and writes, every other access being to write a register address. Note that the CCAR itself can be accessed in a single read or write operation: for example, on a 16-bit bus to write a command to the RTCmd field, software doesn’t have to first write the address of the CCAR (which is zero). Specifying a register address for the next access to the CCAR can be done in the same write operation with issuing a command in RTCmd and/or changing the RTMode field.

‘The RxD and TxD Pins’ in Chapter 4 describes how the RTMode field in the CCAR controls echoing and looping between the Transmitter and Receiver. Typically this field is zero, but in applications using indirect register addressing and non-zero RTMode values, software must take care to preserve the current value of RTMode when it writes register addresses to the CCAR.

When using indirect addressing, some hardware/software mechanism has to prevent a USC interrupt, or any interrupt that leads to a context switch away from an interrupted USC task, from occurring between the time an address is written into the CCAR and when the subsequent read or write is done. This is because an address that has been written into the CCAR is part of the interrupted task’s context that would want to be saved, but there’s no way to read such an address out of the USC — reading the CCAR returns the contents of the addressed register.

The USC always interprets a U//L bit in the “little-Endian” fashion, with a 1 indicating the more-significant 8 bits of the register. U//L should be 0 for all 16-bit accesses.

UM97USC0100

2-9

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

2.9.5 About the Register Address Tables

Tables 2-1 and 2-2 show the names and addresses of the addressable registers in the USC, in address and alphabetical order. The Tables assume that SRightA (BCR0) is

1. The RegAddr column in the Tables reflects the state of AD5-AD1, AD13-AD9, or CCAR5-1 as applicable.

If “16-bit” (BCR2) is 1, the B//W bit from AD6, AD14, or CCAR6 selects between a 16-bit transfer (if 0/low) and an 8-bit transfer (if 1). If “16-bit” is 0, the USC ignores AD6, AD14, or CCAR6 (as applicable). Note that the values in the “8-bit data” columns of Tables 2-1 and 2-2 include the B//W bit 1 for both direct and indirect addressing, as is required on a 16-bit bus. When 16-bit (BCR2) is 0 these address values can be used as shown, or 64 lower like the addresses shown in the “16-bit data” columns.

For 8-bit transfers on either an 8- or 16-bit bus, the state of AD0, AD8, or CCAR0 selects the less-significant 8 bits of the register (if 0/low) or the more-significant 8 bits if 1/high. In this regard the USC is “little Endian” like Intel microprocessors. For 16-bit transfers, AD0, AD8, or CCAR0 must be 0/low.

The Direct Address columns of the Tables assume: (1) SRightA (BCR0) is 1,

(2) the processor’s multiplexed AD6-AD0 lines are con-

nected to AD6-AD0, or its A5-A0 lines are connected to AD13-AD8, depending on SepAd (BCR15),

(3) the D//C pin is grounded, and

(4) the processor’s A7 line is connected to A//B.

If your design differs from these assumptions, register addressing will be different from that shown in the Direct Address columns.

Reset

14 13 12 1 1 10 9 8 7 6 5 4 3 2 1 015

Chan Load

RegAddrRTMode

U//LRTCmd B//W

Figure 2-8. The Channel Command/Address Register (CCAR)

2-10

UM97USC0100

ZILOG

UM009402-0201

Start: Host Cycle

with /CS Low -

which register to R/W?

Z16C30 USC

USER'S MANUAL

SEPAD

(BCR15)

(Separate Addr)1

Activity

on /AS after

Reset?

(Non-Mux'ed Bus)No

Capture iA//B:=A//B,

RegAd = AD13-AD8,

iD/C = D//C at fall

of /DS, /RD, or /WR

(No Separate

Ad)

Yes

(Mux'ed Bus)

Activity

on /AS after

Reset?

(Mux'ed Bus)

Yes

Capture iA/B:=A/B,

B//W:=AD6, RegAd:=

AD5-0, iD/C:=D//C

at rise of /AS

Capture iA//B:=A//B

RegAd = AD13-AD8,

iD/C = D//C

at rise of /AS

RegAd = 0?

No (Non-Mux'ed

Bus)

Yes

Capture iA/B:=A//B,

iD/C:=D//C at fall

of /DS, /RD, or /WR

iD//C

Low/0

Using channel iA//B,

B//W:=CCAR6;

RegAd:=CCAR5-0;

then CCAR5-0:=0

(Control)

High/1

(Serial)

Force B//W : = 1 (Byte)

iD/C

Low /0

RegAd

= 1x000?

(Control)

High/1 (Data)

Yes

16-Bit

(BCR2)

Read 1 or 2 cha-

racters from channel

(iA//B)'s RxFIFO,

depending on B//W

Access the register

in Channel (iA//B)

selected by RegAd,

8/16 bits per B//W

Read

B//W = Not 16-Bit

(BCR2)

Read

Write?

Write

Write 1 or 2 characters to channel (iA//B)'s TxFIFO,

depending on B//W

UM97USC0100

Figure 2-9. USC Register Addressing

2-11

Z16C30 USC

UM009402-0201

ZILOG

USER'S MANUAL

2.9 Register Addressing (Continued)

Table 2-1. USC Registers, in Address Order

CCAR6-0 Indirect Address Channel A Reg or Channel B Direct Address Direct Address:

Channel Command/Address CCAR 00000 0/0 64,65/40,1 128/80 192,3/C0,1 Channel Mode CMR 00001 2/2 66,7/42,3 130/82 194.5/C2,3 Channel Command/Status CCSR 00010 4/4 68,9/44,5 132/84 196,7/C4,5

Channel Control CCR 00011 6/6 70,1/46,7 134/86 198,9/C6,7 Test Mode Data TMDR 00110 12/0C 76,7/4C,D 140/8C 204,5/CC,D Test Mode Control TMCR 00111 14/0E 78,9/4E,F 142/8E 206,7/CE,F

Clock Mode Control CMCR 01000 16/10 80,1/50,1 144/90 208,9/D0,1 Hardware Configuration HCR 01001 18/12 82,3/52,3 146/92 210,1/D2,3 Interrupt Vector IVR 01010 20/14 84,5/54,5 148/94 212,3/D4,5

Input/Output Control IOCR 01011 22/16 86,7/56,7 150/96 214,5/D6,7 Interrupt Control ICR 01100 24/18 88,9/58,9 152/98 216,7/D8.9 Daisy-Chain Control DCCR 01101 26/1A 90,1/5A,B 154/9A 218,9/DA,B

Miscellaneous Interrupt Status MISR 01110 28/1C 92,3/5C,D 156/9C 220,1/DC,D Status Interrupt Control SICR 01111 30/1E 94,5/5E,F 158/9E 222,3/DE,F Receive Data RDR 1x000 32/20 96/60 or 97/61 160/A0 224/E0 or (Read only; TDR for Write) 225/E1

Receive Mode RMR 10001 34/22 98,9/62,3 162/A2 226,7/E2,3 Receive Command/Status RCSR 10010 36/24 100,1/64,5 164/A4 228,9/E4,5 Receive Interrupt Control RICR 10011 38/26 102,3/66,7 166/A6 230,1/E6,7

Receive Sync RSR 10100 40/28 104,5/68,9 168/A8 232,3/E8,9 Receive Count Limit RCLR 10101 42/2A 106,7/6A,B 170/AA 234,5/EA,B Receive Character Count RCCR 10110 44/2C 108,9/6C,D 172/AC 236,7/EC,D Time Constant 0 TC0R 10111 46/2E 110,1/6E,F 174/AE 238.9/EE,F

Transmit Data TDR 1x000 48/30 112/70 or 113/71 176/B0 240/F0 or (Write only; RDR for Read) 241/F1 Transmit Mode TMR 11001 50/32 114,5/72,3 178/B2 242,3/F2,3 Transmit Command/Status TCSR 11010 52/34 116,7/74,5 180/B4 244,5/F4,5

Transmit Interrupt Control TICR 11011 54/36 118,9/76,7 182/B6 246,7/F6,7 Transmit Sync TSR 11100 56/38 120,1/78,9 184/B8 248,9/F8,9 Transmit Count Limit TCLR 11101 5/3A 122,3/7A,B 186/B 250,1/FA,B Transmit Character Count TCCR 11110 60/3C 124,5/7C,D 188/BC 252,3/FC,D Time Constant 1 TC1R 11111 62/3E 126,7/7E,F 190/BE 254,5/FE,F

2-12

UM97USC0100

Z16C30 USC

UM009402-0201

ZILOG

Table 2-2. USC Registers, in Alphabetical Order

CCAR6-0 Indirect Address Channel A

Reg or Channel B Direct Address Direct Address:

Channel Command/Address CCAR 00000 0/0 64,65/40,1 128/80 192,3/C0,1 Channel Command/Status CCSR 00010 4/4 68,9/44,5 132/84 196,7/C4,5 Channel Control CCR 00011 6/6 70,1/46,7 134/86 198,9/C6,7

Channel Mode CMR 00001 2/2 66,7/42,3 130/82 194.5/C2,3 Clock Mode Control CMCR 01000 16/10 80,1/50,1 144/90 208,9/D0,1 Daisy-Chain Control DCCR 01101 26/1A 90,1/5A,B 154/9A 218,9/DA,B

Hardware Configuration HCR 01001 18/12 82,3/52,3 146/92 210,1/D2,3 Input/Output Control IOCR 01011 22/16 86,7/56,7 150/96 214,5/D6,7 Interrupt Control ICR 01100 24/18 88,9/58,9 152/98 216,7/D8.9

Interrupt Vector IVR 01010 20/14 84,5/54,5 148/94 212,3/D4,5 Miscellaneous Interrupt Status MISR 01110 28/1C 92,3/5C,D 156/9C 220,1/DC,D Receive Character Count RCCR 10110 44/2C 108,9/6C,D 172/AC 236,7/EC,D

Receive Command/Status RCSR 10010 36/24 100,1/64,5 164/A4 228,9/E4,5 Receive Count Limit RCLR 10101 42/2A 106,7/6A,B 170/AA 234,5/EA,B Receive Data RDR 1x000 32/20 96/60 or 97/61 160/A0 224/E0 or (Read only; TDR for Write) 225/E1

USER'S MANUAL

Receive Interrupt Control RICR 10011 38/26 102,3/66,7 166/A6 230,1/E6,7 Receive Mode RMR 10001 34/22 98,9/62,3 16 /A2 226,7/E2,3 Receive Sync RSR 10100 4 /28 104,5/68,9 168/A8 232,3/E8,9

Status Interrupt Control SICR 01111 30/1E 94,5/5E,F 158/9E 222,3/DE,F Test Mode Control TMCR 00111 14/0E 78,9/4E,F 142/8E 206,7/CE,F Test Mode Data TMDR 00110 12/0C 76,7/4C,D 140/8C 204,5/CC,D

Time Constant 0 TC0R 10111 46/2E 110,1/6E,F 174/AE 238.9/EE,F Time Constant 1 TC1R 11111 62/3E 126,7/7E,F 190/BE 254,5/FE,F Transmit Character Count TCCR 11110 60/3C 124,5/7C,D 188/BC 252,3/FC,D

Transmit Command/Status TCSR 11010 52/34 116,7/74,5 180/B4 244,5/F4,5 Transmit Count Limit TCLR 11101 58/3A 122,3/7A,B 186/BA 250,1/FA,B Transmit Data TDR 1x000 48/30 112/70 or 113/71 176/B0 240/F0 or (Write only; RDR for Read) 241/F1

Transmit Interrupt Control TICR 11011 54/36 118,9/76,7 182/B6 246,7/F6,7 Transmit Mode TMR 11001 50/32 114,5/72,3 178/B2 242,3/F2,3 Transmit Sync TSR 11100 56/38 120,1/78,9 184/B8 248,9/F8,9

UM97USC0100

2-13

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

2.9.6 Serial Data Registers TDR and RDR

The RDR and TDR are actually “the read and write sides of” the same register location. The USC ignores the state of AD4, AD12, or CCAR4 (as applicable) whenever the rest of the address indicates an access to TDR or RDR. For simplicity Tables 2-1 and 2-2 show RDR at the lower address and TDR at the higher one.

The MSBytes of RDR and TDR should never be read or written alone, only as part of a 16-bit access. On a Zilog 16C0x or Motorola 680x0 system, use direct addresses 97 or 113 (61 or 71 hex) for channel B, and 225 or 241 (E1 or F1 hex) for channel A, to select the LSByte for byte transfers. On an Intel-based system, use the addresses 96, 112, 224, or 240 (60, 70, E0, F0 hex) correspondingly, to select the LSByte for byte transfers.

2.9.7 Byte Ordering

Various microprocessors differ on the correspondence between byte addresses and how bytes are arranged within a 16- or 32-bit value. The Zilog Z80 and most Intel processors use what’s sometimes called the “Little-Endian” convention: the least significant byte of a word has the smallest address, and the most significant byte has the largest address.

The Zilog 16C0x and Motorola 680x0 processors are “BigEndian”: they store and fetch the MSByte in the lowestaddressed byte, and the LSByte in the highest address.

2.9.8 Register Read and Write Cycles

Figures 2-10 through 2-13 show the waveforms of the signals involved when the host processor reads or writes a USC register. Separate drawings are included for the signaling on a bus with multiplexed addresses and data, and for a bus with separate address and data lines. On the other hand, since waveforms get pretty boring after the first few, several things have been done to minimize the number of figures.

1. The cases of separate read and write strobes, vs. a

direction line and a common data strobe, have been combined by labelling the strobe traces as “/DS or /RD” and “/DS or /WR”. The direction line R//W is shown in the figures, but a note reminds the reader that its state doesn’t matter with /RD and /WR.

2. The difference between “wait” and “acknowledge”

signaling is handled by showing the /WAIT//RDY trace as “maybe or maybe not” going low, with appropriate labelling. (The USC never asserts a “Wait” indication during a register access cycle.)

Chapter 6 covers details of DMA cycles initiated by an external DMA controller, while Chapter 7 covers interrupt acknowledge cycles.

The actual timing parameters and electrical specifications of the USC are given in the companion publication USC Product Specification.

Addressing of bytes within USC registers is inherently "Little-Endian", such that the MSBytes of registers have odd addresses.

For 16-bit serial data transfers only, two commands in the RTCmd field of the Channel Command/Address Register (CCAR15-11) allow the USC to be used with either kind of processor. The “Select D15-8 First” and “Select D7-0 First” commands control the byte ordering within a 16-bit transfer of serial data, and apply to DMA and processor accesses to RDR and TDR.

2-14

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

ADnn

A//B, D//C

/CS

/SITACK

/PITACK,/WR,(/RD OR /DS),

DMA Acknowledge signals

/AS

R//W

/DS or /RD

/WAIT//RDY

Address

Data

(Required with /DS, not with /RD.)

Wait Mode

Acknowledge Mode

Figure 2-10. A Register Read Cycle with Multiplexed Addresses and Data

UM97USC0100

2-15

ZILOG

UM009402-0201

2.9.7 Register Read and Write Cycles (Continued)

Z16C30 USC

USER'S MANUAL

ADnn

A//B, D//C

/CS

/SITACK

/PITACK, /RD,(/WR or /DS),

DMA Acknowledge signals

/AS

R//W

/DS or /WR

Address Data

(Required with /DS, not with /WR.)

Wait Mode

/WAIT//RDY

Acknowledge Mode

Figure 2-11. A Register Write Cycle with Multiplexed Addresses and Data

2-16

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

ADnn

A//B, D//C

/CS

/SITACK

/PITACK, /WR, (/RD OR /DS),

DMA Acknowledge signals

R//W

/DS or /RD

/WAIT//RDY

Data

(Required with /DS, not with /RD.)

Wait Mode

Acknowledge Mode

Figure 2-12. A Register Read Cycle with Non-Multiplexed Data Lines

UM97USC0100

2-17

ZILOG

UM009402-0201

2.9.7 Register Read and Write Cycles (Continued)

Z16C30 USC

USER'S MANUAL

ADnn

A//B,D//C

/CS

/SITACK

/PITACK,/AS,/RD,(/WR or /DS),

DMA Acknowledge signals

R//W

/DS or /WR

/WAIT//RDY

Data

(Required with /DS, not with /RD)

Wait Mode

Figure 2-13. A Register Write Cycle with Non-Multiplexed Data Lines

Acknowledge Mode

Zilog, Inc. 210 East Hacienda Ave. Campbell, CA 95008-6600 Telephone (408) 370-8000 Telex 910-338-7621 FAX 408 370-8056 Internet: http://www.zilog.com

2-18

UM97USC0100

ZILOG

UM009402-0201

3.1 INTRODUCTION

SER

’s M

ANUAL

CHAPTER 3

A SAMPLE APPLICATION

Z16C30 USC

USER'S MANUAL

Figures 3-1 and 3-2 are schematics of a simple USC application. It includes a USC, an 80186 integrated processor, two EPROMs, two static RAMs, and 3 serial interfaces.

Figure 3-1 includes everything but the serial interfaces. The processor U2 and oscillator X1 et al typically operate at 16 MHz, and provide a 16 MHz SYSCLK that’s included in the jumper blocks on the right side of p.2, so that it can be jumpered into the /TxC or /RxC pin and thus be used for baud rate generation. The 80186' bus features multiplexed address and data so that software doesn’t have to write register addresses into CCAR.

resides in I/O space, one channel being selected by the first of the 186' Peripheral Chip Select outputs (PCS0) and the other channel being selected by the other (PCS1).

The 28-pin EPROM sockets are set up to accept 2764’s, 27128’s, 27256’s, or 27512’s. The 32-pin RAM sockets can accept 32-pin 128Kx8 or 28-pin 32Kx8 static RAMs.

The U10 74FCT240 inverts signals between active-high signals on the 186 and active-low signals on the USC. The /TxREQ and /RxREQ pins of USC channel A are inverted to make the DMA Request 0 and 1 inputs of the 80186' integrated DMA channels. This means that USC channel A can use DMA operation while USC channel B must be interrupt-driven or polled. Since the 186' DMA channels use flow-through (two cycle) operation, channel A’s /TxACK and /RxACK pins are free for use in the serial interfaces.

UM97USC0100

3-1

ZILOG

UM009402-0201

3.1 INTRODUCTION (Continued)

Z16C30 USC

USER'S MANUAL

Figure 3-1. Sample Application

3-2

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

UM97USC0100

Figure 3-2. Serial Interface for Sample Application

3-3

ZILOG

UM009402-0201

3.1 INTRODUCTION (Continued)

Z16C30 USC

USER'S MANUAL

U7-9 are octal latches that capture the address from the 186 and present the latched address to the RAMs and EPROMs. The EPROMs are selected by the Upper Chip Select (/UCS) output of the 186, while the RAMs are selected by the Lower Chip Select (/LCS) output. The USC resides in I/O space, one channel being selected by the first of the 186' Peripheral Chip Select outputs (PCS0) and the other channel being selected by the other (PCS1).

The 28-pin EPROM sockets are set up to accept 2764’s, 27128’s, 27256’s, or 27512’s. The 32-pin RAM sockets can accept 32-pin 128Kx8 or 28-pin 32Kx8 static RAMs.

The U11 PAL16L8 provides some glue logic, as follows:

/UCS =/PCS0 + /PCS1 ;active-low OR of chip selects /NMI =/NO

+/NMI * NC ;debounce latch for NMI

pushbutton

/SWRE =/SWR * /A0 ;write strobe for even-ad-

dressed (LS) RAM

/SWRO =/SWR * /BHE ;write strobe for odd-ad-

dressed (MS) RAM

/INT0 =UAINT * UBINT ;OR two active-low interrupt

Requests to make high-active output

In these equations, “*” indicates a logical AND operation, “+” indicates a logical OR, and “/” indicates negation or a Low state.

All of the USC’s serial interface pins are shown on its right side in Figure 3-1, and appear again on the J3 and J4 jumper headers at the upper right of Figure 3-2. From there they can be connected in various ways, either jumpered back among J3 and J4, or connected to the serial interfaces via the J5 and J6 jumper headers.

Similarly, J6 leads to 75ALS194 RS-422 differential drivers and 75ALS195 RS-422 differential receivers, whose opposite sides are connected to the user’s choice of an RS-530 DB25 arranged “DTE” style or “DCE” style, or to a DIN Circular-8 connector arranged as a LocalTalk (Appletalk) interface. When using an RS-530 interface, jumper the J7 3-pin header between pins 2 and 3, for Appletalk jumper it between 1 and 2 and connect a “Data Terminal Ready” signal (typically Tx Acknowledge) to pin 5 of J6.

The following signals are typically jumpered straight across between (J3 or J4) and (J5 or J6):

Pin Signal Serial Interface Signal

1 USC TXD —> DTE TxD or DCE RxD 2 USC RXD <— DTE Rx Data or DCE Tx Data 3 USC /RxACK —> DTE Request to Send or DCE

Clear to Send

4 USC /CTS <— DTE Clear to Send or DCE

Request to Send

5 USC /TxACK —> DTE Data Terminal Ready or

DCE Data Set Ready

The connection of other signals is more flexible and application-dependent. The possibilities include, but are not limited to:

USC J3/4 J5/6 pin pin pin Serial interface Signal

/DCD 6 7 —> DCE Data Carrier Detect /DCD 6 8 <— DTE Data Carrier Detect /RxC 8 11 —> DCE Rx Clock /RxC 8 12 <— DTE Rx Clock /TxC 9 13 —> DTE Tx Clock (DTE source)

or DCE Tx Clock (DCE source)

/TxC 9 14 <— DTE Tx Clock (DCE source)

or DCE Tx Clock (DTE source)

/TxREQ 11 15 —> DCE Ring Indicator

(see note 1)

/TxREQ 11 16 <— DTE Ring Indicator

(see note 1)

/RxREQ 12 6 <— DTE Data Set Ready or

DCE Data Terminal Ready (see note 1)

J5 leads to two MAX238 RS232 driver-receivers, whose opposite sides are connected to the user’s choice of an RS-232 DB25 arranged “DTE” style or “DCE” style.

3-4

Note 1: For channel A, these J3 pins should be connected only if they are not used as DMA Requests.

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

Zilog, Inc. 210 East Hacienda Ave. Campbell, CA 95008-6600 Telephone (408) 370-8000 Telex 910-338-7621 FAX 408 370-8056 Internet: http://www.zilog.com

UM97USC0100

3-5

ZILOG

UM009402-0201

4.1 INTRODUCTION

SER

’s M

ANUAL

CHAPTER 4

SERIAL INTERFACING

Z16C30 USC

USER'S MANUAL

The USC® includes several serial interface options and features that promote its usefulness in various kinds of applications. It allows a variety of clocking schemes, and will do serial encoding and decoding for NRZI and Biphase formats that carry clocking information with the serial data. The USC further supports such decoding with an on-chip

4.2 SERIAL INTERFACE PIN DESCRIPTIONS

RxDA,B. Received Data (inputs, positive logic). The serial

inputs for each channel.

TxDA,B. Transmit Data (outputs, positive logic). The serial

outputs for each channel.

/RxCA,B. Receive Clock (inputs or outputs). These signals

can be used as a clock input for any of the functional blocks within each channel. Or, software can program a channel so that this pin is an output carrying any of several receiver or internal clock signals, a general-purpose input or output, or an interrupt input.

/TxCA,B. Transmit Clock (inputs or outputs). These sig-

nals can be used as a clock input for any of the functional blocks within each channel. Or, software can program a channel so that this pin is an output carrying any of several transmitter or internal clock signals, a general-purpose input or output, or an interrupt input.

/RxREQA,B. Receive DMA Request (inputs or outputs).

These pins can carry a low-active DMA Request from each channel’s receive FIFO. If DMA transfers aren’t used for a channel’s receiver, its RxREQ pin can be used as a general-purpose input or output, or as an interrupt input.

/TxREQA,B. Transmit DMA Request (inputs or outputs).

These pins can carry a low-active DMA Request from each channel’s transmit FIFO. If DMA transfers aren’t used for a channel’s transmitter, its TxREQ pin can be used as a general-purpose input or output, or as an interrupt input.

Digital Phase Locked Loop circuit. Finally, it provides I/O lines that can be connected to modem control and status signals, to other control and status lines related to the serial link, or even to input and/or output signals that aren’t related to the serial link at all.

/RxACKA,B. Receive DMA Acknowledge (inputs or out-

puts). If an external “flyby” DMA controller is being used for a channel’s received data, this pin carries the low-active Acknowledge signal from the DMA controller. If DMA transfers aren’t used for a channel’s receiver, or if the DMA controller uses flow-through (two-cycle) rather than flyby operation, that channel’s RxACK pin can be used as a general-purpose input or output.

/TxACKA,B. Transmit DMA Acknowledge (inputs or out-

puts). If an external “flyby” DMA controller is being used for a channel’s transmit data, this pin carries the low-active Acknowledge signal from the DMA controller. If DMA transfers aren’t used for a channel’s receiver, or if the DMA controller uses flow-through (two-cycle) rather than flyby operation, that channel’s TxACK pin can be used as a general-purpose input or output.

/DCDA,B. Data Carrier Detect (inputs or outputs, active

low). Software can program a channel so that this signal enables/disables its receiver. In addition or instead, software can program a channel to request interrupts in response to transitions on this line. The pins can also be used as simple inputs or outputs.

/CTSA,B. Clear to Send (inputs or outputs, active low).

Software can program a channel so that this signal enables/disables its transmitter. In addition or instead, software can program a channel to request interrupts in response to transitions on this line. The pins can also be used as simple inputs or outputs.

UM97USC0100

4-1

ZILOG

UM009402-0201

4.3 TRANSMIT AND RECEIVE CLOCKING

Z16C30 USC

USER'S MANUAL

The USC’s Receiver and Transmitter logic have separate internal clock signals that we’ll call RxCLK and TxCLK. In most of the USC’s operating modes, the Receiver samples a new bit on RxD once per cycle of RxCLK, and the Transmitter presents a new bit on TxD for each cycle of TxCLK. One exception is asynchronous mode, in which RxCLK and TxCLK run at 16, 32, or 64 times the bit rate on RxD and TxD respectively. The other exception involves Biphase-encoded serial data, for which the Receiver samples RxD on both edges of RxCLK, and the Transmitter may change TxD on both edges of TxCLK.

Figure 4-1 shows how RxCLK and TxCLK can be derived in several different ways. This flexibility is an important part of the USC’s ability to adapt to a wide range of applications.

In the simplest case, external logic derives clocks indicating bit boundaries, and software programs the channel to take RxCLK directly from the /RxC pin and TxCLK directly from the /TxC pin. When a channel uses such external clocking for synchronous operation with “NRZ” data, it samples a new bit on the RxD pin on each rising edge on /RxC, and presents each new bit on the TxD pin on the falling edge of /TxC.

It is often desirable to vary the bit rates for transmission and reception by programming the USC, rather than by means of off-chip hardware. To provide for this, each channel includes independent means by which high-speed clocking on /RxC or /TxC can be divided down to almost any desired bit rate.

4.3.1 CTR0 and CTR1

There are two separate 5-bit counters called CTR0 and CTR1 in each channel of a USC, comprising the “first stage” of the channel’s clock-generation logic. Figure 4-2

shows the Clock Mode Control Register. Its CTR0Src and CTR1Src fields (CMCR13-12 and CMCR15-14 respec-

tively) control whether each counter runs and whether it takes its input from the /RxC or /TxC pin:

Figure 4-3 shows the Hardware Configuration Register. Its

CTR0Div field (HCR15-14) controls the factor by which

CTR0 divides its input to produce its output:

CTR0Div CTR0 operation

00 CTR0 output = input/32 01 CTR0 output = input/16 10 CTR0 output = input/8 11 CTR0 output = input/4

There were not enough register bits to allow a separate

2-bit “CTR1Div” field. If the CTR1DSel bit in the Hardware

Configuration Register (HCR13) is 0, the CTR0Div field determines the factor by which both CTR1 and CTR0 divide their inputs to produce their outputs. If CTR1DSel is 1, the DPLLDiv field in the Hardware Configuration Register (HCR11-10) determines the factor by which both CTR1 and the DPLL divide their inputs to produce their outputs. In either case, the channel interprets the selected 2-bit field as shown above for CTR0Div.

The output of either counter can be used directly as RxCLK and/or TxCLK. It can be used as the input to either of two Baud Rate Generators called BRG0 and BRG1, and it can be routed to the /RxC or /TxC pin.

4.3.2 The Baud Rate Generators

There are two 16-bit down counters called BRG0 and BRG1 in each channel of a USC; they form the “second stage” of the channel’s clock-generation logic. The

BRG0Src and BRG1Src fields in the Clock Mode Control

BRGnSRC BRGn clock source

00 CTR0 output 01 CTR1 output 10 /RxC pin 11 /TxC pin

CTRnSRC CTRn clock source

00 CTRn disabled 01 Reserved (disabled) 10 CTRn input = /RxC pin 11 CTRn input = /TxC pin

4-2

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

CTR1/P1

TxCLK

BRG1

MUX

HALF

MODE

CMCR5-3

TC1R

HCR5-4

RxCLK

MUX

DPLL

HALF

CMCR2-0

CTR0/P0

TC0R

BRG0

MODE

HCR1-0

RxCHAR

RxC

MUX

CTR0/P0

RxSYNC

IOCR2-0

TxCHAR

TxC

MUX

CTR1/P1

TxCMPL

DPLL

IOCR5-3

MUX

CMCR9-8

MUX

HCR15-14

CTR0

MUX

CMCR13-12

MUX

1-10

CMCR1

CTR0

CMCR15-14

MUX

HRC13

BRG1

BRG0

DPLL

MODE

TE RA

REFCLK

MUX

HCR9-8

1-10

HCR1

CMCR7-6

Figure 4-1. A Model of a USC Channel’s Clocking Logic

TxC

RxC

UM97USC0100

RxD

4-3

ZILOG

UM009402-0201

4.3.2 The Baud Rate Generators (Continued)

Z16C30 USC

USER'S MANUAL

CTR1Src

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

CTR0Src

Figure 4-2. The Clock Mode Control Register (CMCR)

CTR0Div

CTR1

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

CVOK DPLLDiv DPLLMode TxAMode BRG1S BRG1E RxAMode BRG0S BRG0E

DSel

Figure 4-3. The Hardware Configuration Register (HCR)

Each of the two Time Constant registers (TC0R and TC1R)

contains a 16-bit starting value for the corresponding BRG down-counter. Zero in a Time Constant Register makes a BRG’s output clock identical with its input clock; a value of one makes a BRG divide its input clock by two, and so on — the all-ones value makes a BRG divide its input clock by 65,536 to produce its output clock. This flexibility of dividing by any value means that a channel can derive almost any baud rate from almost any input clock, unlike some competing devices that constrain the system designer to use specified crystal or oscillator values and constrain the available speeds to certain commonly-used baud rates.

The BRG0E and BRG1E bits in the Hardware Configura-

tion Register (HCR0 and HCR4 respectively; the “E” in the names is for “Enable”) control whether each Baud Rate Generator runs or not. A 0 in one of these bits inhibits/ blocks down-counting by the corresponding BRG, keeping the current value in the down counter unchanged despite transitions on the selected input clock. A 1 in one of these bits enables the corresponding BRG to count down in response to input clock transitions.

When a Baud Rate Generator counts down to zero, it sets

the BRG0L/U or BRG1L/U bit in the Miscellaneous Inter-

rupt Status Register (MISR1 or 0). Once one of these bits is set, it stays set until software writes a 1 to the bit, to “unlatch” it”.

TxCLKSrcDPLLSrcBRG0SrcBRG1Src

RxCLKSrc

A BRG may or may not continue to operate after counting

down to zero, depending on the BRG0S or BRG1S bit in

the Hardware Configuration Register (HCR1 or HCR5 respectively; the “S” stands for “Single cycle”). A 0 in BRGnS causes BRGn to reload the TCn value automatically and continue operation, while BRGnS=1 makes BRGn stop when it reaches 0.

Software can (re)load the value in the Time Constant register(s) into one or both BRG counters by writing a "Load TC0", "Load TC1", or "Load TC0 and TC1" command to the RTCmd field of the Channel Command/Address Register (CCAR15-11), as described in the Commands section of Chapter 4. These commands also restart a BRG that’s in Single Cycle mode and has counted down to zero and stopped.

The TC0RSel bit in a channel’s Receive Interrupt Control Register (RICR0) and the TC1RSel bit in its Transmit

Interrupt Control Register (TICR0) control what data the channel provides when software reads the TC0R and TC1R register addresses. If a TCnRSel bit is 0, the channel returns the time constant value last written to TCn. When a 1 is written to a TCnRSel bit, the channel captures the current value of the BRGn counter into a special latch, and thereafter returns the captured value from this latch when software reads the TCn address. Note that in order to obtain a series of relatively current values of a running BRGn, software has to write a 1 to the TCnRSel bit just before each time it reads the TCn location.

4-4

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

The output of either Baud Rate Generator can be used as RxCLK and/or TxCLK. It can be used as the reference clock input to the Digital Phase Locked Loop (DPLL) circuit, and it can be output on the /RxC or /TxC pin.

When a Baud Rate Generator isn’t used to make a serial clock, software can use it for other purposes such as protocol timeouts, and can program the channel to request an interrupt when it counts down to zero. Chapter 6 covers interrupts in detail, but to use BRG interrupts software should write 1’s to the BRG1 IA bit and/or BRG0 IA bit in the Status Interrupt Control Register (SICR1 and/or SICR0), as well as to the MIE and Misc IE bits in the Interrupt Control Register (ICR15 and ICR0).

4.3.3 Introduction to the DPLL

There is one Digital Phase Locked Loop (DPLL) circuit in each channel of a USC; it represents the “third stage” of the channel’s clock-generation logic. The DPLL is a 5-bit counter with control logic that monitors the serial data on

RxD. The DPLLSrc field of the Clock Mode Control Regis-

ter (CMCR7-6) controls which signal the DPLL uses as its nominal or reference clock:

DPLLSrc DPLL Reference Clock

A later section describes the operation of the DPLL in greater detail, but for now it’s sufficient to note that it samples the (typically encoded) data stream on RxD to produce separate receive and transmit outputs. These outputs are synchronized to the bit boundaries on RxD, and can be used as RxCLK and/or TxCLK and/or can be routed to the /RxC or /TxC pin.

4.3.4 TxCLK and RxCLK Selection

The Transmitter can take its TxCLK from any of the sources described in preceding sections, under control of the

TxCLKSrc field of the Clock Mode Control Register

(CMCR5-3):

TxCLKSrc Source of TxCLK

000 No clock (xmitter disabled) 001 /RxC pin 010 /TxC pin 011 Tx output of DPLL 100 BRG0 output 101 BRG1 output 110 CTR0 output 111 CTR1 output

00 BRG0 output 01 BRG1 output 10 /RxC pin 11 /TxC pin

The DPLLDiv field of the Hardware Configuration Register

(HCR11-10) determines whether the DPLL divides this reference clock by 8, 16, or 32 to arrive at its nominal bit rate, as follows:

DPLLDiv Nominal DPLL Clock

00 reference clock/32 01 reference clock/16 10 reference clock/8 11 Reserved (/4 for CTR1)

The 11 value cannot be used for DPLL operation, but if the DPLL isn’t used, software can program this value, together with a 1 in the CTR1DSel bit (HCR13), to operate CTR1 in “divide by four” mode.

Similarly, the Receiver can take its RxCLK from various

sources, under control of the RxCLKSrc field of the Clock

Mode Control Register (CMCR2-0):

RxCLKSrc Source of RxCLK

000 No clock (receiver disabled) 001 /RxC pin 010 /TxC pin 011 Rx output of DPLL 100 BRG0 output 101 BRG1 output 110 CTR0 output 111 CTR1 output

UM97USC0100

4-5

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

4.3.5 Clocking for Asynchronous Mode

For asynchronous reception, transitions on RxCLK don’t have to have any relationship to transitions on RxD. When the Receiver is searching for a start bit, it samples RxD in each cycle of RxCLK, which it divides by 16, 32, or 64 to determine the bit rate. After the Receiver finds the 1-to-0 transition at the beginning of each start bit, it counts off the appropriate number of RxCLK cycles to the middle of the bit cell (8, 16, or 32). At this point it samples RxD to validate the start bit. If RxD has gone back to 1, the Receiver ignores the prior transition as line noise and goes back to searching for a start bit. If RxD is still 0, the Receiver accepts the start bit. Then it counts off 16, 32, or 64 RxCLK cycles to the middle of each subsequent bit of the character, and samples RxD at those times.

For asynchronous transmission, if a Transmitter has been idle and software then provides it with data and enables it, it drives TxD from 1 to 0 for the Start bit at the falling edge on TxCLK that follows the latter of these two steps. It applies each subsequent bit to TxD after counting off 16, 32, or 64 TxCLK cycles. When sending successive async characters, the Transmitter waits for the stop bit length programmed in the two MSBits of the TxSubMode field of the Channel Mode Register (CMR15-14), before driving TxD from 1 to 0 for a subsequent start bit. If these bits specify “shaved” operation, the Transmitter adjusts the stop bit length per the TxShaveL field of the Channel Control Register (CCR11-8).

4.3.6 Synchronous Clocking

Except in asynchronous operation, one cycle on RxCLK corresponds to one data bit on RxD, and one TxCLK cycle corresponds to one bit on TxD. In any of the synchronous modes, the clock used by the receiver to sample the data must be similar to the one used by the remote transmitter to send the data.

common practise to encode the data so that serial stream also includes clocking information. For such applications, the USC can encode transmitted data and decode received data in any of several popular formats.

In addition, each channel’s Digital Phase Locked Loop (DPLL) module can recover a synchronized RxCLK from the received data. While the DPLL can source TxCLK as well, such operation propagates some of the clock jitter from this station’s receive path onto its transmit path, which may increase the error rate.

4.3.7 Stopping the Clocks

CMOS circuits like those in the USC don’t draw much power compared to older technologies, but their power requirements can be reduced still further if their clock signals are stopped when the circuits don’t need to operate. Most of this power savings can be obtained by having the software disable RxCLK and TxCLK by writing zeroes to the RxCLKSrc and TxCLKSrc fields (CMCR2-0 and CMCR5-3). If the Counters and Baud Rate Generators are used, power consumption is reduced further if software disables them by writing zeroes to as many as possible among CTR0Src, CTR1Src, BRG0Src, and BRG1Src (CMCR13-12, CMCR15-14, CMCR9-8, and CMCR11-10). The ultimate in power savings is obtained by having external logic stop the input clock(s) on the /RxC and/or /TxC pins.

When RxCLK is stopped, previously-received data can be read from the RxFIFO, but RxD is ignored so that no further data will arrive. A final character will be available to the software and/or the Receive DMA controller if RxCLK runs for at least three cycles after its last bit is sampled from RxD. For HDLC/SDLC this means at least 3 RxCLKs after the receiver samples the last bit of a closing Flag. For Async it means at least 3 RxCLKs after the receiver samples the stop bit of the last character.

The simplest way to ensure this is to use a separate wire to send the clock from one station’s transmitter to the other station’s receiver. But often cost or the nature of the serial medium prevents this — for example, you can’t send a separate clock over a telephone line. In such cases it is

4-6

TxCLK can be stopped after the last desired bit has gone out on TxD. This is 2 or 3 TxCLKs after the last bit has left the Transmit shift register (because of the Transmit encoding logic), which in turn occurs 1 or 2 TxCLKs after the Transmitter sets the TxUnder bit (TCSR1).

UM97USC0100

ZILOG

UM009402-0201

4.4 DATA FORMATS AND ENCODING

Z16C30 USC

USER'S MANUAL

The USC’s Transmitter and Receiver can handle data in

any of the eight formats shown in Figure 4-4. The RxDecode

field in the Receive Mode Register (RMR15-13) controls

the format for the Receiver, and the TxEncode field in the

Transmit Mode Register (TMR15-13) controls it for the Transmitter. The channel interprets both fields as follows:

xMR15-13 Data Format

000 NRZ 001 NRZB 010 NRZI-Mark 011 NRZI-Space 100 Bi-phase-Mark 101 Bi-phase-Space 110 Bi-phase-Level 111 Differential Biphase-Level

110010Data Bit:

NRZ

Non-Return-to-Zero (NRZ) mode doesn’t involve any en-

coding: at the start of each bit cell the transmitter makes

TxD low for a 0 or high for a 1. NRZB mode is similar except

that the transmitter and receiver invert the data: a low is a 1 and a high is a 0.

NRZB

NRZI-Mark

NRZI-Space

Biphase-Mark

Biphase-Space

Biphase-Level

Differential

Biphase-Level

DPLL TxCLK (All Modes)

DPLL RxCLK (NRZ Modes)

DPLL RxCLK

(Biphase Modes)

UM97USC0100

Note: No assumption is made about the starting state of the serial data in this figure.

As a result, those encoding schemes that operate in terms of transitions rather than

levels are shown with dual traces corresponding to their two possible starting states.

Figure 4-4. Data Formats/Encoding

4-7

ZILOG

UM009402-0201

4.4 DATA FORMATS AND ENCODING (Continued)

Z16C30 USC

USER'S MANUAL

In NRZI-Mark mode, at the start of each bit cell the transmitter inverts TxD for a 1 but leaves it unchanged for a 0. In NRZI-Space mode, at the start of each bit cell the transmitter inverts TxD for a 0 but leaves it unchanged for a 1.

None of these NRZ-type modes, by itself, guarantees transitions in the data stream. However, if the serial protocol can guarantee transitions often enough, then the DPLL can use these transitions to recover a clock from the data stream. By some method the protocol must eliminate long bit sequences without transitions in the data: successive zeroes for NRZ, NRZB, and NRZI-Mark and successive ones for NRZ, NRZB, and NRZI-Space.

For example, NRZI-Space mode matches up well with HDLC and SDLC protocols, because the Transmitter inserts a extra zero into the data stream whenever the transmitted data would otherwise produce six ones in succession. Thus, there is at least one transition every seven bit times.

The reliability of clock recovery from any kind of NRZ data stream depends on guaranteed transitions, on the transmitter’s and receiver’s time bases being reasonably similar/accurate, and on fairly low phase distortion in the

serial medium. Such schemes have the advantage that bits can be sent at rates up to the maximum switching rate (baud rate) of the medium.

The four Bi-phase modes, on the other hand, provide highly reliable clock recovery and do not constrain the content of the data, but they limit the data rate to half the switching rate (baud rate) of the serial medium.

See the waveform for Bi-phase-Mark mode in Figure 4-4. This encoding scheme is also known as FM1. The transmitter always inverts the data at the start of each bit cell. At the midpoint of the cell it changes the data again to indicate a 1-bit, but leaves the data unchanged for a zero. In BiphaseSpace mode (FM0) the transmitter always inverts the data at the start of each bit cell. In the middle of the cell it changes the data again for a zero-bit but leaves the data unchanged for a one-bit. In Biphase-Level mode (also called Manchester encoding), at the start of the bit cell the transmitter makes TxD high for a one-bit and low for a zero. It always inverts TxD in the middle of the cell. In Differential Biphase Level mode, at the start of each bit cell the transmitter inverts TxD for a zero but leaves it unchanged for a one. It always inverts TxD in the middle of the cell.

4.5 MORE ABOUT THE DPLL

While the Transmitter and Receiver must be programmed for the particular serial format to be used, the DPLL only needs to know the general category of encoding on RxD,

in the DPLLMode field of the Hardware Configuration

DPLLMode DPLL Operation/Decoding

00 DPLL disabled 01 Any NRZ mode 10 Biphase-Mark or -Space 11 Either Biphase-Level mode

In any of the NRZ modes, transitions on RxD occur only at the boundaries between bit cells. The DPLL synthesizes a clock having falling edges at bit cell boundaries and rising edges in the middle of the cells. The Transmitter changes TxD on falling edges of TxCLK and the Receiver samples data on rising edges of RxCLK.

In the Bi-phase-Mark and Bi-phase-Space encodings, there is always a transition at the boundaries between active data bits, and there may or may not be a transition at the center of each bit cell. The DPLL generates a receive clock having its falling edge 1/4 of the way through the bit cell, and its rising edge at the 3/4 point. The Receiver determines each data bit from the state of RxD at rising edges of RxCLK and checks for “missing clocks” around falling edges. The DPLL generates a Transmit clock that is the same as in NRZ modes. The Transmitter complements the state of TxD at each falling edge of TxCLK, and may or may not change TxD at rising edges, depending on the current data bit. The DPLL produces clock transitions only when it is "in sync" as described on the next page.

4-8

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

In the Bi-phase-Level and Differential Bi-phase-Level encodings, there is always a transition at the midpoint of each active data bit, and there may or may not be transitions at the boundaries between bit cells. The DPLL generates clocks as for Bi-phase-Mark and -Space, but must know the difference between those modes and these to do

RCCF

Ovflo

RCCF

Avail

Clear

RCCF

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

DPLL

Sync

DPLL 2Miss

DPLL

1Miss

DPLLEdge

Figure 4-5. The Channel Command/Status Register (CCSR)

The DPLL does not include logic to track the clock frequency of the remote end in a long-term manner. Rather it is a counter that is affected by transitions on RxD, and uses the reference clock to make bit clocking that is more or less synchronized to these transitions. Figure 4-5 shows the

USC’s Channel Command/Status Register. Its DPLLEdge

field (CCSR9-8) provides further control over DPLL operation. For most applications, this field should be 00, in which case the DPLL resynchronizes its counter on both rising and falling edges on RxD.

For NRZ applications in which one kind of edge is significantly more precise than the other, software can program the DPLLEdge field to 10 or 01, to make the DPLL ignore one kind of transition. One example of such an application is a serial bus with passive external pull-ups; in such a application, falling edges are more accurate than rising edges. If DPLLEdge is 11, the DPLL never resynchronizes — that is, it runs freely like CTR0 and CTR1.

Because the blocking of edges by DPLLEdge affects missing clock detection as well as resynchronization, for Biphase operation DPLLEdge should always be programmed as 00.

In any NRZ mode, when the DPLL is in sync, it uses the selected nominal value (8, 16, or 32 cycles of its input clock) for counting off the next bit cell if a transition on RxD falls near the bit cell boundary. If a transition comes early it uses the nominal value minus 1 for the next cell, while if a transition comes late it uses the nominal value plus one. In /16 and /32 modes only, the DPLL uses the nominal value plus two for the next bit cell if a transition comes very late in a cell, and the nominal value minus two if a transition comes very early.

so. The Receiver determines each data bit from the state of RxD at falling edges of RxCLK and checks for “missing clocks” around rising edges. The Transmitter may or may not change TxD at falling edges of TxCLK, depending on the current data bit. It always inverts TxD at rising edges.

Loop

Send Loop

Rsrvd

TxResidue

/TxACK

/RxACK

“clock” transitions in the fourth and first quarters of the cell. If a clock transition falls very close to the cell boundary, the DPLL uses the nominal value (8, 16, or 32) as the length of the next bit cell. Otherwise it uses the nominal value minus one if a clock transition comes early, or the nominal value plus one if a clock transition is late.

In Bi-phase-Level or Differential Bi-phase-Level modes, when the DPLL is in sync it ignores “data” transitions in the first and fourth quarters of the bit cell, and resynchronizes to “clock” transitions in the second and third quarters of the cell. If a clock transition falls close to the middle of the cell, the DPLL uses the nominal value (8, 16, or 32) as the length of the next bit cell. Otherwise it uses the nominal value minus one if a clock transition comes early, or the nominal value plus one if the clock transition is late.

In an NRZ mode, if there’s no transition in a bit cell the DPLL uses the nominal value (8, 16, or 32 clocks) as the length of the next bit cell. It also does this in Biphase modes, if there is no clock transition in a bit cell when the DPLL is in sync. In particular, in these cases the DPLL doesn’t reapply a correction from a previous bit cell.

In Bi-phase modes, the CVOK bit in the Hardware Control

Register (HCR12) controls whether the Receiver flags a single code violation as an error. If CVOK=0, it sets the DPLL1Miss bit for a single code violation as described below. If CVOK=1, it doesn’t report a single code violation in DPLL1Miss; use this setting when the protocol includes single code violations as normal occurrences, as in the 1533B mode that’s described in Chapter 5. Regardless of CVOK, code violations in two consecutive bit cells set the DPLL2Miss and DPLLDSync L/U bits and de-synchronize the DPLL.

In Bi-phase-Mark or Bi-phase-Space modes, when the DPLL is in sync it ignores “data” transitions in the second and third quarters of the bit cell, and resynchronizes to

UM97USC0100

4-9

ZILOG

UM009402-0201

4.5 MORE ABOUT THE DPLL (Continued)

Z16C30 USC

USER'S MANUAL

After software sets up the DPLL, three bits in the Channel Command/Status Register (CCSR) provide the operating interface. The logic enters a “fast sync mode” when soft-

ware writes a 1 to the DPLLSync bit (CCSR12), or in a

Biphase mode when it detects two consecutive missing clocks. In this mode, the next RxD transition (that’s allowed by the DPLLEdge field) resynchronizes the DPLL counter and puts the DPLL “back in sync”.

The DPLL watches the RxD line for transitions, and classifies them as either clock or data. Depending on the position of transitions within each bit cell, the logic adjusts the phase of the DPLL output clock to synchronize the clock with the bit cell boundaries of the incoming data. “Fast Sync” tells the DPLL that the NEXT edge it sees is the one to synchronize to; otherwise the DPLL has to see “n” correct edges before becoming “in sync.” “n” is about three for X8 mode, six for X16, and 12 for X32.

The time required to get in sync in the worst case is thus a function of the data encoding method, as well as the data on the line. The key issue is the number of “edges” the DPLL sees on RxD.

The DPLLSync bit in the Channel Command/Status Register (CCSR12) reads as 1 if the DPLL is in sync. The

DPLL2Miss bit (CCSR11) reads as 1 if the DPLL is in a

biphase mode and has detected missing clocks in two

consecutive bit cells. The DPLL1Miss bit (CCSR10) reads

as 1 if the DPLL is in a biphase mode, the CVOK bit (HCR12) is 0, and the DPLL has detected a missing clock in at least one cell. Once DPLL2Miss or DPLL1Miss is 1, it continues to read that way until software writes a 1 to it.

Writing a 0 to any of DPLLSync, DPLL2Miss, or DPLL1Miss has no effect on the DPLL logic.

The channel sets the DPLLDSync L/U bit when it loses

sync in a Biphase mode. This bit is similar to DPLL2Miss in that once it’s set, it stays that way until software writes a 1 to the bit to “unlatch” it. Chapter 7 explains how to program a channel so that it interrupts the host processor when it sets DPLLDSync.

4.6 THE RXD AND TXD PINS

In some sense these are the most important pins on a USC. Typically they carry the serial input to the Receiver and the serial output of the Transmitter respectively. Figure 4-6

shows the I/O Control Register. Its TxDMode field (IOCR7-

6) allows software to control the function of TxD:

TxDMode Function of the TxD pin

00 Totem-pole Transmitter output 01 High-impedance state 10 Low output 11 High output

CTSMode RxRModeTxRMode TxCModeTxDMode RxCMode

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

DCDMode

Figure 4-6. The Input/Output Control Register (IOCR)

Software can use the ability to drive TxD low to generate a Break condition in Asynchronous applications. The duration of such a Break is fully under software control.

The ability to put the TxD pin in a high-impedance state allows software to use the USC in “serial bus” schemes that include multiple senders on the same signal line. (But note that the TxDMode field resets to 00, so that the channel drives TxD after a Reset until the software programs TxDMode to 01.) The ability for direct programmable control over the TxD pin allows software to “bit-bang” unusual/occasional serial protocol requirements, while keeping the USC’s full power for more standard and everyday communications.

4-10

UM97USC0100

ZILOG

UM009402-0201

The RTMode field of the Channel Command/Address

register (CCAR9-8) controls the relationship between the Transmitter and the Receiver and thus between the TxD and RxD pins. It is encoded as follows:

RTMode Operation

00 Normal operation: the Transmitter and

Receiver are completely independent.

01 Echo mode: the state of the RxD pin is

copied directly onto the TxD pin. Data from the Transmitter is ignored.

10 Pin Controlled Local Loop: the data from

the TxD pin, as determined by the TxDMode field (IOCR7-6), is routed to the Receiver rather than the data from RxD. If TxDMode specs TxD as high impedance, the Receiver can take its input from a remote source via TxD rather than RxD.

11 Internal Local Loop: the data from the

Transmitter is routed to the Receiver rather than the data from RxD, regardless of the setting of the TxDMode field (IOCR7-6).

Z16C30 USC

USER'S MANUAL

4.7 EDGE DETECTION AND INTERRUPTS

Software can program each channel to detect rising and/ or falling edges on the /CTS, /DCD, /TxC, /RxC, /TxREQ, and /RxREQ pins, and to interrupt when such events occur. Figure 4-7 shows that the Status Interrupt Control Register (SICR) includes separate Interrupt Arm (IA) bits for rising and falling edges on each of these pins. (Chapter 7 describes the USC’s interrupt features in detail.) A 1 in one of these bits makes the channel detect that kind of edge, while a 0 makes it ignore such edges. This edge detection and interrupt mechanism operates without regard for whether the various pins are programmed as inputs or outputs in the I/O Control Register (IOCR).

When a channel detects an edge that’s enabled in the SICR, it records the event in an internal “edge detection latch” for that input. This latch is not directly accessible in the USC’s register map. Instead, as shown in Figure 4-8, the Miscellaneous Interrupt Status Register (MISR) in-

cludes two bits for each of these six pins, one called a “Latched/Unlatch” or L/U bit, and the other being a “data bit” that has the same name as the pin itself.

A hardware or software Reset sequence clears all the L/U bits to zero. While the L/U bit for a pin is 0, the associated data bit reports and tracks the state of the pin in a “transparent” fashion, with a 1 indicating a low and a 0 indicating a high.

Whenever a pin’s L/U bit is 0 and its internal edgedetection latch is set, the channel sets the L/U bit to 1, clears the detection latch, and sets the I/O Pin Interrupt Pending (IOP IP) bit. IOP IP can be read and cleared (and if necessary set) in the Daisy Chain Control Register (DCCR1). Chapter 7 describes how the I/O Pin Enable and Master Interrupt Enable bits determine whether the IP bit actually results in an interrupt request to the processor.

UM97USC0100

4-11

ZILOG

UM009402-0201

4.7 EDGE DETECTION AND INTERRUPTS (Continued)

Z16C30 USC

USER'S MANUAL

RxCDn

RxCUp

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

TxCDn

TxCUpIARxRDnIARxRUp

TxRDn

TxRUp

Figure 4-7. The Status Interrupt Control Register (SICR)

RxCL/U TxRL/UTxCL/U

/RxC

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

/TxC

RxRL/U /RxREQ /TxREQ

Figure 4-8. The Miscellaneous Interrupt Status Register (MISR)

While an L/U bit is 1, the state of the associated data bit is frozen (latched). These two bits remain in this state, regardless of further transitions on the pin, until software writes a 1 to the L/U bit. This clears the L/U bit to 0 and “opens” the data latch to once again report and track the state of the pin, at least for an “instant”. If one or more enabled transitions occurred while the L/U bit was set, then L/U is set again right after software writes the 1 to it.

L/U

DPLL

DSync

DPLL

DSync

L/U

BRG1IABRG0

BRG1

L/U

BRG0

L/U

DCDDn

DCDL/U

DCDUpIACTSDn

/DCD

CTSL/U

CTSUp

/CTS

RCC

Under

RCC

Under

One mode in which software can use this logic is to read the MISR, then immediately write back what it has read. The software should then look for 1’s in any and all “interesting” L/U bits, and process/handle all such changes without rereading the MISR. To obtain the current state of one of these pins, regardless of the L/U bit, software can write a 1 to the L/U bit and then immediately read back the MISR.

Writing a 0 to an L/U bit has no effect, and the channel ignores data written to the “data” bits.

4-12

UM97USC0100

ZILOG

UM009402-0201

4.8 THE /DCD PIN

Z16C30 USC

USER'S MANUAL

The DCDMode field of the I/O Control Register (IOCR13-

12) controls the function of this pin:

DCDMode Function of the /DCD pin

00 Low-active Rx Carrier input 01 Low-active Rx Sync input 10 Low output 11 High output

When DCDMode is 00, software can handle the Carrier indication all by itself. Or, the /DCD signal can enable and disable the Receiver in hardware if software also programs the RxEnable field of the Receive Mode Register (RMR1-

0) to 11. In the latter case, the Receiver starts assembling a character only when /DCD is low; if /DCD goes high during a received character, the Receiver aborts/discards it. Figure 4-9 shows how the required relationship between /DCD and RxD varies depends on the Receiver mode:

■ For isochronous mode, /DCD should set up low to the

rising edge of RxCLK at which the receiver samples the start bit on RxD.

■ For monosync, bisync, and transparent bisync, /DCD

should set up low to the rising edge of RxCLK that precedes the one at which the receiver samples the first bit of the last sync pattern before the message.

■ For HDLC/SDLC mode, /DCD should set up low to the

rising edge of RxCLK at which the receiver samples the ending 0 of the last Flag before the frame.

DCDMode=01 identifies the /DCD pin as an input from external sync detection logic. Software typically programs this value in conjunction with programming the RxMode field of the Channel Mode Register (CMR3-0) with 0001 for External Sync operation or 1001 for 802.3 (Ethernet) operation. For External Sync mode, external logic should drive the /DCD pin low so that it sets up to the rising edge of RxCLK before the one at which the Receiver should capture the first data bit. For 802.3 /DCD should go low when carrier is detected — a figure in Chapter 5 shows that the timing relationship to RxD isn’t critical but /DCD should go low no later than 6 bits into the 64 alternating bits that precede the frame. The Receiver starts sampling RxD at the same rising edge of RxCLK at which it first samples /DCD low. If /DCD goes high during a received character, the Receiver completes receiving the character and transfers it to the Receive FIFO before going inactive.

Sync conditions generated internal to the channel are not output on this pin as on certain predecessor devices, but can be output on the /RxC pin as described later.

The /DCD pin can alternatively be used as a generalpurpose output. To do this, simply program DCDMode to 10 to make the channel drive /DCD low, and to 11 to drive the pin high. For such an application the designer may want to connect a pull-up or pulldown resistor to the /DCD pin, because the channel will not drive the pin from the time /RESET goes low until the software programs DCDMode to 10 or 11.

UM97USC0100

4-13

ZILOG

UM009402-0201

4.8 THE /DCD PIN (Continued)

/DCD

RxCLK

(/RxC)

Z16C30 USC

USER'S MANUAL

RxD (Async, 9-Bit

ACV/1553B

RxD (Isochronous)

RxD (External Sync)

RxD (Monosync, Bisync,

Transparent Bisync)

RxD (HDLC)

0111111

Figure 4-9. /DCD Auto-Enable Timing

Software can program a channel to interrupt the host processor on either or both edges on /DCD, as described in the preceding section. Typically such interrupts would be used when /DCD is an input, that is, when DCDMode is

00 or 01. Software should write a 1 to the DCDDn IA bit in

the Status Interrupt Control Register (SICR7) to make a channel detect falling edges on /DCD, and write a 1 to

DCDUp IA (SICR6) to make it detect rising edges.

Start Bit

Start

Bit

1st Bit

Received

Last 0

of Flag

1st Bit

of Sync

1st Bit

of Frame

Rest of Sync Character(s)

As described in the preceding section, the DCDL/U bit

(MISR7) is 1 if the channel has detected an enabled edge,

until software writes a 1 to the bit to clear it. The /DCD bit

(MISR6) reflects the state of the /DCD pin transparently while DCDL/U is 0, but is frozen while DCDL/U is 1. MISR6=0 indicates a high on the pin, and 1 indicates a low.

4-14

UM97USC0100

ZILOG

UM009402-0201

4.9 THE /CTS PIN

Z16C30 USC

USER'S MANUAL

The CTSMode field of the I/O Control Register (IOCR15-

14) controls the function of this pin:

CTSMode Function of the /CTS pin

0x Low-active Clear to Send input 10 Low output 11 High output

/CTS

TxCLK

(/TxC)

TxD

When CTSMode is 00 or 01, software can handle the Clear to Send input all by itself. Alternatively, the /CTS input can enable and disable the Transmitter in hardware, if software writes 11 to the TxEnable field of the Transmit Mode Register (TMR1-0). In the latter case, the Transmitter will start sending a character only when /CTS is low. As shown in Figure 4-10, if the Transmitter is otherwise “ready to go” when /CTS goes low, the first bit active bit on TxD will begin at the falling edge of TxCLK that is 4.5 clock periods after the rising edge of TxCLK at which the Transmitter first samples /CTS low.

4.5 Clocks 1st Active Bit

Figure 4-10. /CTS Auto-Enable Timing

If /CTS goes high during a transmitted character in an asynchronous mode, the Transmitter finishes sending the character before going inactive. In the same situation in a synchronous mode, the Transmitter terminates transmission immediately.

The /CTS pin can alternatively be used as a generalpurpose output. To do this, simply program CTSMode to 10 to make the channel drive /CTS low, and to 11 to make it drive the pin high. For such applications the designer may want to connect a pull-up or pulldown resistor to the /CTS pin, because the channel won’t drive the pin from the time /RESET goes low until the software programs CTSMode to 10 or 11.

Software can program a channel to interrupt the host processor on either or both edges on /CTS, as described in the earlier section "Edge Detection and Interrupts". Typically such interrupts would be used when /CTS is an input, that is, when CTSMode is 00 or 01. Software should

write a 1 to the CTSDn IA bit in the Status Interrupt Control

on /CTS, and write a 1 to CTSUp IA (SICR4) to make it

detect rising edges.

As described in Edge Detection and Interrupts, the

CTSL/U bit (MISR5) is 1 if the channel has detected an

enabled edge, until software writes a 1 to the bit to clear it.

The /CTS bit (MISR4) reflects the state of the /CTS pin

transparently while CTSL/U is 0, but is frozen while CTSL/U is 1. MISR4=0 indicates a high on the pin, and 1 indicates a low.

UM97USC0100

4-15

ZILOG

UM009402-0201

4.10 THE /RXC AND /TXC PINS

Z16C30 USC

USER'S MANUAL

Figure 4-1 shows each channel’s options for the function of

its /RxC and /TxC pins. The RxCMode field in the Input/

Output Control Register (IOCR2-0) controls the function of /RxC:

RxCMode Function of the /RxC pin

000 /RxC is an input 001 /RxC outputs RxCLK 010 /RxC outputs Rx Character Clock 011 /RxC outputs /RxSYNC 100 /RxC carries the BRG0 output 101 /RxC carries the BRG1 output 110 /RxC carries the CTR0 output 111 /RxC carries the DPLL Rx output

while the TxCMode field (IOCR5-3) controls the function of

the /TxC pin:

TxCMode Function of the /TxC pin

000 /TxC is an input 001 /TxC outputs TxCLK 010 /TxC outputs Tx Character Clock 011 /TxC outputs “Tx Complete” 100 /TxC carries the BRG0 output 101 /TxC carries the BRG1 output 110 /TxC carries the CTR1 output 111 /TxC carries the DPLL Tx output

Some of these possible outputs need further description. A channel drives its Rx Character Clock high for one RxCLK period as it transfers each character from the Receive shift register to the Receive FIFO. Similarly, it

drives its Tx Character Clock high for one TxCLK period each time it transfers a character from the Transmit FIFO to the Transmit shift register. A channel’s /RxSYNC output goes low for one RxCLK cycle each time its Receiver recognizes a Sync or Flag sequence. The Tx Complete output is suitable for controlling a driver on TxD. It is low from the start of the first active bit of a sequence of one or more consecutively-transmitted characters, through the end of the last bit of the sequence. The BRG and CTR outputs are square waves. The DPLL outputs were shown earlier in this chapter.

While it’s not very useful to employ a high-speed freerunning clock as a source of interrupt events, for other uses of /RxC and /TxC software can program a channel to interrupt the host processor on either or both edges on these pins, as described in the earlier section Edge Detection and Interrupts. Typically such interrupts would be used for an input pin, that is, when RxCMode or TxCMode

is 00 or 01. Software should write a 1 to the RxCDn IA or TxCDn IA bit in the Status Interrupt Control Register

(SICR15 or SICR13) to make a channel detect falling

edges on /RxC or /TxC, and write a 1 to RxCUp IA or TxCUp IA (SICR14 or SICR13) to make it detect rising

edges.

As described in Edge Detection and Interrupts, the

RxCL/U or TxCL/U bit (MISR15 or MISR13) is 1 if the

channel has detected an enabled edge, until software

writes a 1 to the bit to clear it. The /RxC or /TxC bit (MISR14

or MISR12) reflects the state of the pin transparently while the L/U bit is 0, but is frozen while the L/U bit is 1. A 0 in MISR14 or MISR12 indicates a high on the pin, and 1 indicates a low.

4-16

UM97USC0100

ZILOG

UM009402-0201

4.11 THE /RXREQ AND /TXREQ PINS

Z16C30 USC

USER'S MANUAL

The RxRMode and TxRMode fields of the I/O Control

XxRMode Function of /XxREQ pin

00 Input pin 01 DMA Request output

(or Interrupt Request) 10 Low output 11 High output

Chapter 6 describes the DMA Request function, whereby a channel signals an off-chip DMA controller when its TxFIFO or RxFIFO reaches a programmed degree of “readiness” for DMA data transfer.

Chapter 7 suggests another use for these pins if they’re not used as DMA requests, namely as interrupt request outputs that are separate from /INT. This is advantageous in a system in which the host processor and bus provide multiple interrupt request levels and the software uses them for nested interrupts. See 'Using /RxREQ and /TxREQ as Interrupt Requests' in Chapter 7 for more details.

Software can program a channel to interrupt the host processor on either or both edges on these pins, as described in the earlier section 'Edge Detection and Interrupts'. Typically such interrupts would be used for an input pin, that is, when RxRMode or TxRMode is 00. Software

should write a 1 to the RxRDn IA or TxRDn IA bit in the

Status Interrupt Control Register (SICR11 or SICR9) to make a channel detect falling edges on /RxREQ or

/TxREQ, and program RxRUp IA or TxRUp IA (SICR10 or

SICR8) to 1 to make it detect rising edges.

As described in Edge Detection and Interrupts, the

RxRL/U or TxRL/U bit (MISR11 or MISR9) is 1 if the

channel has detected an enabled edge, until software

writes a 1 to the bit to clear it. The /RxR or /TxR bit (MISR10

or MISR9) reflects the state of the pin transparently while the L/U bit is 0, but is frozen while the L/U bit is 1. A 0 in MISR10 or MISR9 indicates a high on the pin, and 1 indicates a low.

4.12 THE /RXACK AND /TXACK PINS

The RxAMode and TxAMode fields of the Hardware

Configuration Register (HCR3-2 and HCR7-6 respectively) control the function of these pins:

XxAMode Function of /XxACK pin

00 General-purpose input 01 DMA Acknowledge input 10 Low output 11 High output

Chapter 6 describes the DMA Acknowledge function, whereby an off-chip DMA controller signals a USC channel that a “flyby” or single-cycle DMA operation is occurring in response to the channel’s assertion of the corresponding REQ pin, and that the channel should provide data on, or capture data from, the AD pins.

The USC does not provide transition-detection, latching, or interrupt capabilities for the /RxACK and /TxACK pins as it does for most of the other signals described in this chapter. Therefore, if these pins aren’t used as DMA Acknowledge inputs, they can be used either for outputs or for noncritical polled inputs.

The two LSBits of the Channel Command/Status Register (CCSR1 and CCSR0) allow software to sense the state of a channel’s ACK pins if they’re used as general-purpose

inputs. Figure 4-5 shows the CCSR. Its /TxACK and /RxACK bits are forced to 0 unless the corresponding

TxAMode or RxAMode field in the HCR is 00, in which case the bit reads back as a 0 when the /TxACK or /RxACK pin is high and 1 when the pin is low.

UM97USC0100

4-17

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

Zilog, Inc. 210 East Hacienda Ave. Campbell, CA 95008-6600 Telephone (408) 370-8000 Telex 910-338-7621 FAX 408 370-8056 Internet: http://www.zilog.com

4-18

UM97USC0100

ZILOG

UM009402-0201

5.1 INTRODUCTION

SER

’s M

ANUAL

CHAPTER 5

SERIAL MODES AND PROTOCOLS

Z16C30 USC

USER'S MANUAL

The main advantage of USC® family members is that they can communicate in many different modes and serial protocols. This, in turn, makes for more flexible and capable products for Zilog’s customers. This chapter de-

5.2 ASYNCHRONOUS MODES

Figure 5-1 shows how a "start bit" precedes each character in async communications, and that so-called "stop bits" separate characters. A start bit is a period of space/zero that’s the same length as each following data bit. Each stop bit is a period of mark/one that's more that half a bit time long, with a typical minimum duration of one bit time. (The USC and other devices offer the ability to “shave” stop bits to less than a bit time.) In most forms of async, the falling edge between a stop bit and the next start bit can come any time after this minimum stop bit duration. In other words, the length of the stop bit does not have to be any particular multiple of the nominal bit time.

To handle this variability in the length of stop bits, asynchronous receivers “oversample” the received serial data at some multiple of the nominal bit frequency. Software can set up a USC Receiver to do this at 16, 32, or 64 samples/ bit. When a Receiver is waiting for a start bit and successive samples reveal a falling edge, it typically samples again one-half bit time later, to validate the start bit. If the serial data is still space/zero, the receiver then samples the following data bits and stop bit at their nominal centers after that. If the hardware samples the stop bit as space/ zero, the associated character is invalid or at least highly suspect.

scribes how to set up and use the USC in its various modes of serial operation. These modes can be classified into three major categories: asynchronous, character-oriented synchronous, and bit-oriented synchronous protocols.

Some async protocols check further for serial link errors by including a parity bit with each character. The transmitter generates such a bit so that the total number of 1 bits in the character is odd or even. The receiving station checks each parity bit. If it finds an incorrect one, it discards the character and/or notifies the operator(s) of the receiving and/or transmitting machine(s). But a single parity bit is not a very reliable checking method — it can be easily deceived by errors that affect more than one bit. Few async applications use parity checking nowadays, although they may generate it, in case they find themselves talking to equipment that does. Where protection against line errors is important, some async applications may use blockoriented checking as described below for synchronous protocols.

Each USC channel can handle a variety of options within “classic” async operation, plus several unique variants. In isochronous mode, the data format is similar to classic async, but external hardware supplies a bit-synchronized 1x clock instead of a 16x, 32x, or 64x clock. In Nine-Bit mode, an extra bit differentiates between “address” characters that select a particular destination on a multi-station link, and subsequent data characters.

UM97USC0100

5-1

ZILOG

UM009402-0201

5.2 ASYNCHRONOUS MODES (Continued)

Z16C30 USC

USER'S MANUAL

1/2 Bit Time

Receiver detects

Falling Edge

Receiver validates

Start Bit

Start

Bit

5 to 8 Data Bits,

Plus Optional Parity Bit

Receiver Samples Data

(and Parity?) Bits

Receiver checks

Figure 5-1. Asynchronous Data

Stop Bit

Stop

Bit

Minimum 1 Bit Time

(except for "Shaving")

All 1 Bit TIme

Start

Bit

SYN (16)

STX

(16)

Message

STX (02)

Data

ETX (03)

CRC

May be SYNs, Mark,

Space, or Not Driven

Figure 5-2. Character Oriented Synchronous Data

SYN

(16)

SYN (16)

5-2

UM97USC0100

ZILOG

UM009402-0201

5.3 CHARACTER ORIENTED SYNCHRONOUS MODES

Z16C30 USC

USER'S MANUAL

These protocols came into use after async, in an effort to get better line utilization by eliminating start and stop bits. In sync modes, characters follow one another directly on the serial link, each consisting of an agreed-upon number of bits and each bit having the same nominal length. Since bits and characters occur at regular intervals, the datacom hardware can typically handle higher bit rates because it doesn’t have to oversample as in typical async applications. This effect combines with having fewer bits per character, to make synchronous operation substantially faster than async.

In character oriented sync modes, “special” characters divide the data into “messages”. Figure 5-2 shows how the transmitter sends some minimum number of agreed-upon “sync characters” between messages. When a synchronous receiver begins to receive a message, it typically starts in a “search mode” in which it samples successive bits into its serial-to-parallel shift register. It does this until the last N bits match a defined sync pattern. Then the Receiver enters a mode in which it simply captures each succeeding group of bits as a character.

Most sync protocols require the receiving station to validate the sync pattern match. It can do this by checking whether the next character is another sync, an agreedupon “start of message” character, or perhaps one of a small set of such characters. This validation can be done by software or by hardware.

Almost all character-oriented synchronous protocols also define one or more characters, or sequences of characters, to mark the end of a message. Instead of (or sometimes besides) parity checking on each character, synchronous protocols will typically include a checking code covering most or all the characters in each message. The transmitter accumulates and sends this code before or after the end-of-message character or sequence. Early sync protocols used a Longitudinal Redundancy Character (LRC) that was simply the parallel Exclusive Or of the characters in the message. Newer protocols use various kinds of Cyclic Redundancy Checking (CRC) which offer greater reliability in exchange for a somewhat more involved method of computation. Either kind of message checking can be computed by either hardware or software at the Transmitter and Receiver. The USC channels can automatically generate and check various kinds of CRCs in synchronous modes.

Synchronous applications vary considerably in terms of the line state between messages. In half-duplex operation, each station typically stops driving the line after the end of a message. The other side then starts driving it to “turn the line around”. In full-duplex point-to-point environments, a transmitter may send a stream of repeated Sync or Idle characters between messages. This maintains synchronization between itself and the remote receiver as to character boundaries. This avoids the need to send several sync characters before the start of the next message, when it becomes available for transmission. In other full-duplex environments, the line may be maintained at a constant Mark or Space between messages.

While many modes have several variants, the top level of a USC channel’s control hierarchy includes the following character-oriented synchronous modes. In Monosync mode, the hardware transmits or matches a sync character of eight bits or less. Software must handle further receive-sync validation. In Bisync mode the hardware transmits or matches a minimum of two sync characters. The two can be the same or different codes, each of eight bits or less. Transparent Bisync mode is similar to Bisync mode except that the prefix character Data Link Escape (DLE) precedes control characters. This allows the transmission of arbitrary “binary” data without conflict with the various control characters. Slaved Monosync mode applies only to the Transmitter, making it operate in conformance with the X.21 standard, such that it sends characters in byte-synchronism with those received. External Sync mode applies only to the Receiver, and leaves all syncdetection and framing control to external circuitry. An input signal simply enables the Receiver to assemble characters from the RxD line.

The final character-oriented synchronous mode of the USC channels provides basic facilities for IEEE 802.3 (Ethernet) operation. At the start of a frame, the Transmitter generates, and the Receiver detects, a preamble consisting of alternating 0 and 1 bits ending with two 1’s in succession. Bi-phase-level data encoding must be selected in the Transmit and Receiver Mode Registers (TMR and RMR), as described in Chapter 4. External hardware must be provided to detect collisions and to signal the Transmitter when they occur. External hardware also must signal the Receiver when a frame ends based on loss of carrier. Upon collision detection, “back-off” timing must be determined by external hardware or host processor software.

UM97USC0100

5-3

ZILOG

UM009402-0201

5.4 BIT ORIENTED SYNCHRONOUS MODES

Z16C30 USC

USER'S MANUAL

As character-oriented synchronous protocols came into wider use in the 1960’s and 70’s, the number of characters having special significance for the hardware kept increasing. Hand in hand with this, the complexity of the required hardware processing and state machines rose drastically. Particularly troublesome was data “transparency”, the ability to transmit any kind of “binary” data without conflict with the various control characters used in these protocols.

These problems might be less severe were they occurring today. But given the technology available in the 1960’s, the proliferation of sync protocols was making it harder and harder to build general-purpose datacom hardware. Instead, one had to build dedicated communications controllers for each protocol.

Bit oriented synchronous protocols were a response to these problems. IBM’s SDLC was the first one widely used; subsequent standardization efforts added several refinements in defining HDLC. These protocols simultaneously minimized the amount of required hardware support, while lifting all restrictions on the content of the data transmitted.

Figure 5-3 shows how in bit-oriented modes, a frame is a group of sequential characters ending with a CRC code to verify its correctness, as in character-oriented protocols. The difference lies in the Flag sequences used to begin, end, and separate frames.

When a bit-oriented synchronous Receiver starts to receive a frame, it looks for a Flag sequence (01111110) just as a character-oriented synchronous Receiver looks for its sync character. While sending a frame, a bit-oriented synchronous Transmitter continually checks whether any sequence of data bits could look like a Flag. It does this without regard for character boundaries. Whenever the data presented to a Transmitter includes a zero followed by five ones, the Transmitter adds an extra zero-bit after the fifth one-bit. Correspondingly, a bit-oriented synchronous Receiver monitors the serial data stream within a frame; any time it sees 0111110, regardless of character boundaries, it deletes the trailing zero.

Flag (7E)

Frame

CRCData

Suppose that the Data presented to the Transmitter includes:

1110xxxx

yy100111

The Data actually sent will include:

x01111101001y

Extra 0-bit inserted by Transmitter, deleted by Receiver

Flag (7E)

May be Flags, Mark,

Space, or Not Driven

Figure 5-3. HDLC/SDLC Data

Flag (7E)

Data

5-4

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

This relatively simple technique allows transmission of any kind of data and assures uniqueness of the Flag sequence within the data stream. (Uniqueness is assured as long as line errors don’t occur.) This makes for simpler hardware than with some character-oriented synchronous protocols, in that the hardware only has to recognize a few bit sequences. They include 0111111 for zero-bit-stuffing by a Transmitter, 0111110 for bit removal by a Receiver, a Flag sequence, and finally an Abort sequence. An Abort is a zero followed by 7 or more ones.

As mentioned in the previous chapter, SDLC/HDLC protocols match up well with NRZI-Space encoding to ensure data transitions for clock resynchronization. This is because the Transmitter inverts NRZI-space data for every 0bit and there are never more than five 1-bits in succession within a frame.

Finally, since the Flag-matching hardware operates without regard for character boundaries, bit-oriented synchronous protocols can handle frames that are any number of bits in length. (In character-oriented synchronous protocols, messages must be composed of an integer number of characters.)

The USC can handle most variations of SDLC and HDLC protocols, since it leaves the details of almost all such variations to the host software. One variation with hardware significance is Loop mode. In this mode, the Transmitter can forward received data from the “preceding” station in a loop of stations to the “next” one in the loop. When this station has a frame to send, host software can load the start of the frame into the TxFIFO and then enable the Transmitter. The Transmitter then waits until it detects the transmitpermission token called Go Ahead, which is the same as the short-Abort sequence 01111111 in HDLC/ SDLC mode. The Transmitter then changes this character to a Flag and begins transmitting.

5.5 THE MODE REGISTERS (CMR, TMR AND RMR)

Three Mode registers in each channel of the USC control the basic operation and serial protocol of the channel’s Transmitter and Receiver.

The Channel Mode Register (CMR) selects among the various communication protocols mentioned in the preceding sections. Figure 5-4 shows that the MSbyte controls the mode of the Transmitter, while the LSbyte controls that of the Receiver. Software can select the modes of the two modules independently by writing bytes to the CMR, or, on a 16-bit bus, it can set both modes simultaneously using a 16-bit write.

Within each byte, the four LSbits select the major communications protocol. The coding for these fields is similar but not identical because some modes apply only to the Transmitter while others apply only to the Receiver:

TxMode RxMode

Value (CMR11-8) (CMR3-0)

0000 Asynchronous Asynchronous 0001 — External Sync 0010 Isochronous Isochronous 0100 Monosync Monosync 0101 Bisync Bisync 0110 HDLC/SDLC HDLC/SDLC 0111 Transp. Bisync Transp. Bisync 1000 Nine-Bit Nine-Bit 1001 802.3 (Ethernet) 802.3 (Ethernet) 1010 — — 1011 — — 1100 Slaved Monosync — 1101 — — 1110 HDLC/SDLC Loop — 1111 — —

Zilog reserves values shown above as “—” for future use; they should not be programmed in the indicated field.

UM97USC0100

5-5

ZILOG

UM009402-0201

5.5 THE MODE REGISTERS (CMR, TMR AND RMR) (Continued)

Z16C30 USC

USER'S MANUAL

Later sections describe each of these modes and protocols individually, including the significance of the Tx and RxSubMode bits (CMR15-12 and CMR7-4 respectively) in each case. The various major modes use the SubMode bits differently, to control protocol variations and options that are specific to each mode. (Sometimes the same SubMode option applies to two or more related major modes.)

The TxMode field should be changed only while the Transmitter is disabled in the TMR, as described in the next section. Similarly, the RxMode field should be changed

TxSubMode TxRMode RxSubMode RxMode

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

Figure 5-4. The Channel Mode Register (CMR)

only while the Receiver is disabled in the RMR. While it’s possible to change the TxSubMode or RxSubMode fields while the Transmitter or Receiver is operating, the options provided by these fields are typically static in nature and the need to change them should seldom arise.

The Transmit and Receive Mode Registers (TMR and RMR) contain basic control information for the Transmitter and Receiver, including the serial format and data-integrity checking. Figures 5-5 and 5-6 show the TMR and RMR respectively.

TxEncode

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

RxDecode

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

TxCRCType

RxCRCType

Start

TxCRC

Enab

TxCRC

atEnd

TxParType

TxPar

Enab

TxCRC

Figure 5-5. The Transmit Mode Register (TMR)

Start

RxCRC

Enab

QAbort

RxParType

RxPar

Enab

RxCRC

Figure 5-6. The Receive Mode Register (RMR)

TxLength

RxLength

TxEnable

RxEnable

5-6

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

5.5.1 Enabling and Disabling the Receiver and Transmitter

The TxEnable and RxEnable fields (TMR1-0 and RMR1-

0) enable and disable the Transmitter and Receiver to send and receive serial data. 00 in TxEnable disables the Transmitter, so that it keeps its output inactive and doesn’t transfer characters from the TxFIFO to its shift register. Assuming that the TxDMode field (IOCR7-6) is 00 to propagate the Transmitter’s output onto TxD, the pin is a constant Mark/high if the MSBit of the TxIdle field (TCSR10) is 1 and/or the TxEncode field (TMR15-14) is 000 indicating NRZ data. If TxDMode is 00, TCSR10 is 0, and TxEncode is non-zero, the TxD pin carries encoded ones.

If software changes TxEnable to 00 while the Transmitter is sending a character, it discards the character and disables its output immediately. Similarly, 00 in RxEnable disables the Receiver: it ignores the RxD pin and doesn’t assemble characters. If software changes this field to 00 while the Receiver is assembling a character, it discards the partial character.

01 in TxEnable or RxEnable disables the Transmitter or Receiver in a more “graceful” way than 00. If software changes TxEnable to 01 while the Transmitter is sending asynchronous data, it finishes sending the current character before going inactive. If software changes TxEnable to 01 while the Transmitter is sending synchronous data, it finishes sending the current frame or message before going inactive. If software changes RxEnable to 01 while the Receiver is receiving asynchronous data, it finishes assembling the current character before going inactive. If software changes RxEnable to 01 while the Receiver is receiving synchronous data, it finishes receiving the current frame or message before going inactive.

10 in TxEnable or RxEnable enables the Transmitter or Receiver unconditionally.

11 in TxEnable places the Transmitter under the control of the /CTS pin. /CTS should be programmed as an input in the CTSMode field of the Input/Output Control Register (IOCR15-14). In this case, the Transmitter only starts sending a character when /CTS is low. If /CTS goes high while the Transmitter is sending a character in an async mode, it finishes sending the character before going inactive. In any synchronous mode, /CTS high summarily disables the Transmitter. In either case, sooner or later, /CTS high forces TxD to Mark or ones as described above for TxEnable=00.

11 in RxEnable places the Receiver under the control of the /DCD pin. /DCD should be programmed as an input in the DCDMode field of the Input/Output Control Register (IOCR13-12). The Receiver ignores the RxD pin and does not assemble characters when /DCD is high. If /DCD goes high while the Receiver is assembling a character in External Sync mode or 802.3 (Ethernet) mode, it finishes assembling the character and places it in the RxFIFO before going inactive. In any other mode the Receiver discards any partial character when /DCD goes high.

5.5.2 Character Length

The TxLength and RxLength fields (TMR4-2 and RMR4-

2) control how many bits the Transmitter sends and the Receiver assembles in each character. The channel interprets both fields as follows:

xMR4-2 Character Length

000 8 bits 001 1-bit 010 2 bits 011 3 bits 100 4 bits 101 5 bits 110 6 bits 111 7 bits

When TxLength specifies less than 8 bits, the Transmitter discards/ignores one or more of the more-significant bits of each byte that it takes from the TxFIFO.

When RxLength specifies less than 8 bits, the Receiver replicates the most significant received bit in the more significant bits of each byte it places in the RxFIFO. For Async mode, it includes a received Parity bit, if any, in each data byte. If RxLength, plus the Parity bit if any, is less than 8 bits, the Receiver fills out the more-significant bits of each byte with the Stop bit, which is 1 except when there’s a Framing Error.

UM97USC0100

5-7

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

5.5.2 Character Length (Continued)

When RxLength is less than eight in synchronous modes including HDLC/SDLC, the Receiver fills out the more significant bits of each byte with the last received bit (the parity bit if one is used), except in three cases:

1. In Monosync and Bisync modes, when CMR4 is 1 so

that sync characters are 8 or 16 bits long, but data characters contain less than 8 bits, each data character is left-justified in its byte.

2. In HDLC/SDLC mode, when CMR5-4 are non-zero so

that address and control characters are 8 bits long but subsequent characters are less than 8 bits long, each subsequent character is left-justified in its byte.

3. In HDLC/SDLC mode, if the frame doesn’t end on a

character boundary, its final data bits are left-justified within the (right-justified) number of bits specified by RxLength, unless case 2 also applies, in which case they’re left-justified in the last byte. (The number of bits in the last character of each HDLC/SDLC frame is always indicated in the RxResidue field of the RCSR.)

Software should reprogram RxLength only while the Receiver is either disabled, in Hunt state in a synchronous mode, or between characters in an asynchronous mode. Software can reprogram TxLength at any time, but a new length takes effect only when the Transmitter loads the next character into its shift register.

5.5.3 Parity, CRC, Serial Encoding

A later section of this chapter, 'Parity Checking', discusses how bits 7-5 of both the TMR and RMR control parity checking.

Similarly, a later section of this chapter, 'Cyclic Redundancy Checking', describes how bits 12-8 of the TMR and RMR control CRC checking.

The TxEncode and RxDecode fields (TMR15-13 and RMR15-13) specify how the Transmitter encodes serial data on the TxD pin and how the Receiver decodes it on the RxD pin. See Chapter 4 for a full description of the following encodings:

xMR15-13 Data Format

In any of these three cases of left-justified data, the lesssignificant bits are left over from the previous character.

If software enables parity checking in an asynchronous mode, the Transmitter and Receiver handle the parity bit as an additional bit after the number of bits defined by TxLength and RxLength. If software selects parity checking in a synchronous mode, the Transmitter and Receiver handle the parity bit as the last of the number of bits specified by TxLength and RxLength.

000 NRZ 001 NRZB 010 NRZI-Mark 011 NRZI-Space

100 Bi-phase-Mark 101 Bi-phase-Space 110 Bi-phase-Level 111 Differential Bi-phase-Level

5-8

UM97USC0100

ZILOG

UM009402-0201

5.6 ASYNCHRONOUS MODE

Z16C30 USC

USER'S MANUAL

Software can select classic asynchronous operation for both the Transmitter and the Receiver, by programming the TxMode and RxMode fields (CMR11-8 and CMR3-0 respectively) to 0000. The earlier Figure 5-1 shows how a “0” Start bit precedes each character and a “Stop bit” follows each, the latter being a “1” condition that’s more than 1/2 bit time long. The idle state of the line is 1, and the Transmitter and Receiver divide their input clocks by 16, 32, or 64 to arrive at the nominal bit time.

Software can make the Transmitter calculate and send a parity bit with each character and can make the Receiver check such parity bits, as described in the later section Parity Checking.

The two more significant TxSubMode bits (CMR15-14) control the minimum number of Stop bits that the Transmitter sends between consecutive characters. The Transmitter interprets them as follows:

CMR15-14 Minimum Length of Tx Stop

00 One bit time 01 Two bit times 10 One, “shaved” per CCR11-8 11 Two, “shaved” per CCR11-8

The two LSbits of the Tx and RxSubMode fields (CMR1312 and 5-4) control the factors by which the Transmitter and Receiver divide their TxCLK and RxCLK inputs to arrive at the nominal bit length. A channel interprets both fields as follows:

CMR13-12 & CMR5-4 Nominal Bit Length

00 TxClock or RxClock/16 01 TxClock or RxClock/32 10 TxClock or RxClock/64 11 Reserved, do not program

For the Receiver, choosing a larger divisor makes it sample the data on RxD more often. This may result in a slightly better error rate in marginal circumstances. For the Transmitter there is no significance to the divisor chosen, other than the convenience of choosing the same value as for the Receiver, so that the same source can be used for both RxCLK and TxCLK. (See Chapter 4 for more information about clock selection.)

Zilog reserves the two MSbits of the RxSubMode field (CMR7-6) in Asynchronous mode for use in future products. They should always be programmed as 00.

When CMR15 is 1 in this mode, the TxShaveL field of the Channel Control Register (CCR11-8) controls the exact length of the minimum Stop bit(s). If the 4-bit value in TxShaveL is “n”, then the length of the shaved stop bit is (n+1)/16-bit times. The following table summarizes the stop bit possibilities afforded by CMR15-14 and CCR11-8:

Minimum Length of

CMR15-14 CCR11-8 Tx Stop

00 xxxx 1 bit time 01 xxxx 2 bit times 10 0000-0111 1/2 or less: DO NOT USE 10 1000 9/16 10 1001 5/8 10 1010-1110 11/16 to 15/16 10 1111 1 (as with CMR15-14=00) 11 0000 17/16 11 0001 9/8 11 0010-1110 19/16 to 31/16 11 1111 2 (as with CMR15-14=01)

There is no such thing as a “received stop length” parameter: the Receiver does not expect or check for a particular stop bit length. It simply samples the received data at the nominal midpoint of a single Stop bit, and loads a corresponding Framing Error bit into the RxFIFO with each character. This bit migrates through the FIFO with its associated character and eventually appears as the CRCE/FE bit in the Receive Command/Status Register (RCSR3). Note that RCSR3 can represent the status at the time that a character marked with RxBound status was read from the RxFIFO, or the status of the oldest 1 or 2 characters that are still in the RxFIFO, as described in the later section 'Status Reporting'.

UM97USC0100

5-9

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

5.6.1 Break Conditions

A Break condition is a period of Space (zero) state on an Async line, that’s longer than the length of a character. Such a sequence traditionally signals an exceptional condition or a desire to stop transmission in the opposite direction. Alternatively, a Break may mean that the switched or physical connection with the other station is broken. The Receiver detects a Break condition when it samples a supposed Stop bit as Space/zero (a Framing Error) and all the data bits were also Space/zero. In this case the Receiver doesn’t place the all-zero character in the RxFIFO, but instead sets the Break/Abort bit in the Receive Command/Status Register (RCSR5). This bit can be enabled to cause an interrupt at the start of a Break.

If it's necessary to have an interrupt at the end of a Break, software can switch the Receiver to Monosync mode, looking for an all-ones Sync character, and arm the Exited Hunt condition to flag the end of the Break. After the

5.7 ISOCHRONOUS MODE

interrupt, software has to switch back to async mode and purge the Rx FIFO. Alternatively, software can tell when the Break ends by polling the Break/Abort bit. The bit doesn’t go back to 0 until software has written a 1 to the bit to “unlatch” it, and RxD has gone back to 1/High/Mark.

Software can send a Break by programming the TxDMode field of the Input/Output Control Register (IOCR7-6) to 10 to force TxD to low/space. Then it can use whatever kind of timing resources it has available to measure the desired duration of the Break. After this, it can program TxDMode back to 11 to force TxD to high/mark or to 00 to resume normal operation. Chapter 4 describes a channel’s Counters and Baud Rate Generators that may be useful in timing the length of a transmitted Break. While most modern serial controllers will detect a Break that’s only slightly longer than a character, older conventions required a Break to be much longer: 200 milliseconds or more.

Software can select Isochronous operation for the Transmitter and the Receiver, by programming the TxMode and RxMode fields (CMR11-8 and CMR3-0 respectively) to

0010. This mode is similar to Asynchronous mode as described above, except that the Transmitter and Receiver use 1X instead of 16x, 32x, or 64x clocking. This typically means that an external bit clock must be provided. It’s possible to use the DPLL to recover a 1x clock, but this is a lot like what the Receiver does in Async mode anyway.

Of the options available in the Channel Mode Register for Async mode, the only one that applies in Isochronous mode is CMR14. This controls whether the Transmitter sends one or two stop bits:

CMR14 Length of Tx Stop

0 1 bit time 1 2 bit times

The USC doesn’t use the other three bits of the TxSubMode field in Isochronous mode, nor any of the RxSubMode bits, but Zilog reserves these bits for functional extensions in future products. Software should always program them with zeroes in Isochronous mode on a USC.

5-10

UM97USC0100

ZILOG

UM009402-0201

5.8 NINE-BIT MODE

Z16C30 USC

USER'S MANUAL

This mode is compatible with various equipment including some Intel single-chip microcontrollers. In some contexts it’s called “address wakeup mode”. Software can select it for the Transmitter and the Receiver by programming the TxMode and RxMode fields (CMR11-8 and CMR3-0 respectively) to 1000. Operation on the line is similar to Async mode, using a single stop bit and either eight data bits or seven data bits plus a parity bit. Following the eighth (MS) data bit or the Parity bit, an additional bit differentiates normal data characters from “destination address” characters. Address characters identify which of several stations on the link should receive the following data characters. In effect, Nine Bit mode is like a Local Area Network using asynchronous hardware.

The Transmitter saves TxSubMode bit 3 (CMR15) with each character as it goes into the TxFIFO, and sends this bit as that character’s address/data bit. By convention a 0 signifies “data” and a 1 signifies “address”. As software or an external Transmit DMA controller writes each character into the TxFIFO, the channel saves the state of CMR15 with it. This bit accompanies the character through the FIFO and out onto the link.

TxSubMode bit 2 (CMR14) selects between eight data bits or seven data bits plus parity:

RxSubMode bit 2 (CMR6) similarly controls parity checking of characters marked as Data, thus allowing 8-bit data, while a 1 enables parity checking, thus limiting data characters to 7 data bits. The Receiver always checks the parity of address bytes. The RxParEnab bit in the Receive Mode register (RMR5) must be set to the same value as this bit.

As in Async mode, the two LSbits of the Tx and RxSubMode fields (CMR13-12 and CMR5-4) control whether the Transmitter and Receiver divide their TxCLK and RxCLK inputs by 16X, 32X, or 64x to arrive at the nominal bit length. See the preceding Async section for the field encodings and a discussion of the significance of this choice.

The Receiver sets the RxBound status bit for a received address character, that is, a character that has its ninth bit set to 1. This bit accompanies the character through the RxFIFO and ends up in the Receive Command/Status Register (RCSR4). Note that this mode uses the RxBound indicator quite a bit differently from other modes, in that it marks the start of each received block rather than the end. Because of this, some of the mechanisms associated with RxBound, that are described in later sections, aren’t of much use in Nine-Bit mode. For example, you probably wouldn’t want to store a Receive Status Block for an address character.

CMR14 Data bits

0 Eight 1 Seven plus parity

The TxParEnab bit in the Transmit Mode Register (TMR5) must be set to the same value as this bit.

Typically, Nine Bit receivers check the parity of received address bytes. This means that when software selects eight data bits, it must calculate its own parity bit in the MSB of addresses.

The USC doesn’t use the MSBit of the RxSubMode field (CMR7) in Nine Bit mode, but Zilog reserves this bit for future enhancements, and software should program it as 0 in this mode.

UM97USC0100

5-11

ZILOG

UM009402-0201

5.9 EXTERNAL SYNC MODE

Z16C30 USC

USER'S MANUAL

Software can select this mode only for the Receiver, by programming the RxMode field of the Channel Mode Register (CMR3-0) as 0001. This value is not defined for the TxMode field (CMR11-8).

This is the most primitive synchronous mode. To use it, software must program the DCDMode field of the Input/ Output Control Register (IOCR13-12) to 01, to specify that the /DCD pin carries a Sync input. External hardware must provide a low-active signal on this pin, that controls when the Receiver should capture data. When the external hardware establishes synchronization and/or data validity, it should drive /DCD low. The timing should be such that the IUSC first samples /DCD low at the rising edge of RxCLK before the one at which it should capture the first data bit from RxD. (Typically, RxCLK comes directly from the /RxC pin in this mode.)

While /DCD stays low the Receiver samples RxD on each rising edge of RxCLK. Ideally, the external hardware should negate /DCD such that the channel samples it high on the rising RxCLK edge after the one on which it samples

the last bit of the last character. But if /DCD goes high while the Receiver is in the midst of assembling a received character, it continues on to sample the remaining bits of the character and place the character in the RxFIFO. Because of this, it’s OK for /DCD to go high during the last character, at any time after a hold time after the RxCLK edge at which the Receiver samples the first bit of the character.

Software can make the Receiver check a parity bit in each character as described in the following section 'Parity Checking'. Besides or instead of character parity, software can make the Receiver check a CRC code as described in the 'Cyclic Redundancy Checking' section.

The USC doesn’t use the RxSubMode field (CMR7-4) in External Sync mode, but Zilog reserves this field for future enhancements and software should program it as 0000 in this mode.

5.10 MONOSYNC AND BISYNC MODES

The Binary Synchronous Communications protocol put forth by the IBM Corporation in the 1960’s is often abbreviated as “Bisync”. But we will use the latter term more generally, to mean a mode of a USC channel in which the Transmitter sends, and the Receiver searches or “hunts” for, a Sync pattern composed of two characters totalling 16 bits or less. By contrast, we’ll use the term “Monosync” to mean a mode in which the Transmitter sends, and the Receiver matches, a sync pattern of eight bits or less. Use of Bisync mode with the two sync characters equal represents a middle ground, having the advantage that the twocharacter pattern match by the Receiver is more reliable and secure than the sync match in Monosync mode.

Software can select these modes for the Transmitter and/ or the Receiver, by programming the value 0100 (for Monosync) or 0101 (for Bisync) into the TxMode and/or RxMode fields of the Channel Mode Register (CMR11-8 and CMR3-0).

Software can make the Transmitter calculate and send a parity bit with each character and can make the Receiver check such parity bits, as described in the 'Parity Checking' section.

In such character-oriented synchronous modes, blocks of consecutive characters are called 'messages'. Besides or instead of character parity, software can make the Trans-

mitter calculate and send a Cyclic Redundancy Check (CRC) code for each message and can make the Receiver check a CRC in each message, as described later in 'Cyclic Redundancy Checking'.

On the transmit side, the Transmitter “concludes a message” in either of two situations: when it underruns or after it sends a character marked with “EOF/EOM” status. The Transmitter underruns when the TxFIFO is empty and the transmit shift register needs a new character. Software can mark a character as the last one of a message directly, using a command in the Transmit Command/Status Register (TCSR), or more automatically by using the Transmit Character Counter as described in a later section.

The MSBit of the TxSubMode field (CMR15) determines whether the Transmitter sends a CRC when it concludes a message because of an Underrun condition. The TxCRCatEnd bit in the Transmit Mode Register (TMR8) determines whether it does so when it concludes a message because of a character marked as End Of Message. If CMR15 or TMR8 (as applicable) is 1, the Transmitter sends the CRC code that it has accumulated while sending the message. If CMR15 or TMR8 is 0, it doesn’t send a CRC code; if there’s any message-level checking, it must be sent like normal data.

5-12

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

After the CRC, or immediately if CMR15 or TMR8 is 0, in Monosync mode the Transmitter sends the Sync character in the LSByte of the Transmit Sync Register (TSR7-0). In Bisync mode it sends the “SYN1” character in TSR15-8 if CMR14 is 0, while if CMR14 is 1 it sends one or more character pairs. The Transmitter takes the first character of each such pair from TSR7-0; by convention it’s called “SYN0”. The second character of each pair comes from TSR15-8 and is called “SYN1”.

After sending this closing Sync character or pair, if/while software doesn’t present another message, the Transmitter maintains the TxD signal in the “idle line state” defined by the TxIdle field of the Transmit Command/Status Register (TCSR10-8). If this field is 000, it continues to send more of the same Sync character or pair that it sent to terminate the message. Other TxIdle values select constant or alternating-bit patterns, as described later in 'Between Frames, Messages, or Characters'.

If the CMR13 bit in the TxSubMode field is 1, the Transmitter sends a “Preamble” before the “opening” sync character that precedes each message. Software can select the length and content of the Preamble in the Channel Control Register (CCR11-8). A typical use of the Preamble is to send a square-wave pattern for bit rate determination by a phase locked loop.

The Transmitter always sends at least one “opening” Sync pattern before the first data character of a message (after the Preamble if any). In Monosync mode it sends one character from TSR15-8, while in Bisync mode it sends the “SYN0” character from TSR7-0 followed by “SYN1” from TSR15-8. (In Bisync mode an opening Sync sequence is always a character pair, regardless of CMR14.)

The LSBits of the TxSubMode and RxSubMode fields (CMR12 and CMR4 respectively) specify the length of the Sync characters that the Transmitter sends before and after each message and between messages, and for which the Receiver hunts. If CMR12 or CMR4 is 1, sync characters have the same length as data characters, namely the length specified by the TxLength field in the Transmit Mode Register (TMR4-2) or the RxLength field of the Receive Mode Register (RMR4-2). If sync characters are less than 8 bits long, they must be programmed in the least significant bits of TSR15-8, RSR7-0 and, for Bisync, TSR7-0 and RSR15-8. Furthermore, to guarantee that the Receiver matches such Sync characters, the “unused” MSBits among RSR7-0 (and for Bisync RSR15-8) must be programmed equal to the MS active bit.

If CMR12 or CMR4 is 0, Sync characters are 8 bits long regardless of the length of data characters.

On the receive side, the CMR5 bit of the RxSubMode field determines what the Receiver does with Sync characters. In CMR5 is 1, the Receiver strips characters that match the character in RSR15-8, and neither places them in the RxFIFO nor includes them in its CRC calculation. (In Bisync mode, aside from the initial sync match the Receiver treats characters that match “SYN0” in RSR7-0, but don’t match “SYN1” in RSR15-8, as normal data.) If CMR5 is 0, the Receiver places all Sync characters inside a message in the RxFIFO and includes them in the CRC calculation.

The USC doesn’t use the two MSBits of the RxSubMode field (CMR7-5) in Monosync and Bisync modes, nor CMR14 in the TxSubMode field in Monosync mode. Zilog reserves these bits for future enhancements, and software should always program these bits with zeroes in these modes.

UM97USC0100

5-13

ZILOG

UM009402-0201

5.11 TRANSPARENT BISYNC MODE

Z16C30 USC

USER'S MANUAL

This mode is more specific to the Transparent Mode option of IBM Corp.’s Binary Synchronous Communications protocol than is the Bisync mode described above. Software can select this mode for the Transmitter and the Receiver, by programming the TxMode and RxMode fields of the Channel Mode Register (CMR11-8 and CMR3-0) to 0111.

In Monosync and Bisync modes the Sync characters are programmable, but in this mode a channel uses the fixed characters “DLE” for the first of a sync pair, and “SYN” for the second of a pair. (Software can make the Transmitter send only SYNs for closing and idle Syncs.) The LSBits of the TxSubMode and RxSubMode fields (CMR12 and CMR4) control whether the Transmitter and Receiver use the ASCII or EBCDIC codes for control characters, with a 1 specifying EBCDIC.

Besides using DLE before an opening and possibly a closing SYN, the Transmitter can check whether each data character coming out of the TxFIFO is a DLE and insert another DLE if so. This feature allows any kind of data to be sent “transparently”. The Transmitter doesn’t include such an inserted DLE in its CRC calculation. Software can selectively enable and disable this function using the Enable DLE Insertion and Disable DLE Insertion commands, as described later in the 'Commands' section. In general software should enable DLE insertion for sending data and disable it for sending a control sequence that starts with DLE. The channel routes the state controlled by these commands through the TxFIFO with each character, so that software can change the state as needed.

Similarly, in Transparent Bisync mode the Receiver checks whether each character coming out of its shift register is a DLE. If so, it sets a state bit. If the next character is also a DLE, the Receiver doesn’t include it in the RxFIFO nor in the CRC calculation.

If the character after a DLE is a SYN, the Receiver excludes both the DLE and the SYN from the CRC calculation, but places both characters in the FIFO so that they will appear in the received data stream.

If the character after a DLE is any of the terminating codes “ITB”, “ETX”, “ETB”, “EOT”, or “ENQ”, the Receiver places the terminating character in the RxFIFO marked with RxBound status. As described in later sections, this marking may set the channel’s Received Data Interrupt Pending bit and thus force an interrupt request on its /INT pin, and/ or it may force a DMA request on the /RxREQ pin.

The first “DLE-SOH” or “DLE-STX” in a message makes the Receiver enable its CRC generator for subsequent data. Therefore, the CRC in Transparent Bisync mode covers all the data after the first DLE-SOH or DLE-STX.

The Receiver doesn’t take any other special action based on received DLE’s.

A Transmitter in Transparent Bisync mode sends a DLESYN pair at the start of a message, but a Receiver in this mode syncs up to SYN-SYN. This is so that software can determine “transparency” separately for each message, by testing whether the first character of the message in the RxFIFO is a DLE.

The following table shows the ASCII and EBCDIC codes that a channel recognizes in this mode:

Character ASCII Code

EBCDIC Code

DLE 10 10 ENQ 05 2D EOT 04 37

ETB 17 26 ETX 03 03 ITB 1F 1F

SOH 01 01 STX 02 02 SYN 16 32

Given the dedicated nature of the Sync characters, the Transmitter interprets the three MSBits of the TxSubMode field similarly to the way it does so in Bisync mode. If CMR15 is 1, it sends a CRC when a Tx Underrun condition occurs. If CMR14 is 1, the Transmitter sends one or more DLE-SYN pairs after a message, else it just sends SYNs. If CMR13 is 1, it sends a Preamble sequence before the opening Sync at the start of each message.

The same data checking options apply to this mode as in Monosync and Bisync, but since we’re quite protocolspecific here, we can say that character parity is not used while CRC-16 checking is. While the Receiver can detect the end of the frame in Transparent Bisync mode, the Receive Status Block feature can’t be used to capture the CRC Error status of the frame, for reasons discussed later in the 'Cyclic Redundancy Checking' section. But the selective inclusion/exclusion of received data in the CRC calculation, that’s typical of this mode, precludes the kind of automatic reception that the RSB feature allows in modes like HDLC/SDLC anyway.

The USC doesn’t use the three MSBits of the RxSubMode field (CMR7-5) in Transparent Bisync mode, but Zilog reserves these bits for future enhancements and software should always program them as 000 in this mode.

5-14

UM97USC0100

ZILOG

UM009402-0201

5.12 SLAVED MONOSYNC MODE

Z16C30 USC

USER'S MANUAL

This mode applies only to the Transmitter. Software selects it by programming 1100 in the TxMode field of the Channel Mode Register (CMR11-8), while programming 0100 in the RxMode field (CMR3-0) to select Monosync mode for the Receiver.

The mode is intended to implement the X.21 standard and similar schemes in which character boundaries on TxD must align with those on RxD. For this to be meaningful, RxCLK and TxCLK typically come from the same source, as described in Chapter 4.

Most of the setup and operation in this mode is the same as in Monosync mode, which was described in an earlier section. CMR15 determines whether the Transmitter sends a CRC in an Underrun condition. CMR12 selects whether sync characters are the same length as data characters, or are 8 bits long.

CMR13 controls the major operating option in Slaved Monosync mode. (In regular Monosync mode this bit controls whether the Transmitter sends a Preamble before each message; in this mode it can’t send one.)

The Transmitter will not go from an inactive to an active state while CMR13 is 0. If CMR13 is 1 when the Receiver signals that it has matched a Sync character, the Transmitter sets the OnLoop bit in the Channel Command/Status Register (CCSR7) and becomes active. That is to say, the Transmitter can go active at any received Sync character, not just one that makes the Receiver exit from “Hunt mode”.

Once the Transmitter starts, operation is identical with Monosync mode. The Transmitter sends the Sync character from TSR7-0. Then it sends data from the TxFIFO, until the TxFIFO underruns or until it sends a character marked as End of Message. Then the Transmitter sends the CRC if software has programmed that it should do so for this kind of termination. Finally it sends a Sync character and checks the CMR13 bit again.

If CMR13 is still 1, the Transmitter waits, sending the programmed Idle line condition, until the software triggers it to send another message. If, however, software cleared CMR13 to 0 during the message just concluded, or if it does so while the channel is sending the Idle condition, the Transmitter goes inactive but it leaves OnLoop (CCSR7) set. In the inactive state it sends continuous ones until software programs CMR13 back to 1 again, and the Receiver signals Sync detection.

If all the transmitted and received sync and data characters are the same length, and the same clock is used for both the Transmitter and Receiver, this method of starting transmission assures that transmitted characters start and end simultaneously with received characters, as required by X.21.

The USC doesn’t use CMR14 in the TxSubMode field in Slaved Monosync mode, but Zilog reserves this bit for future enhancements and software should always program it as zero in this mode.

UM97USC0100

5-15

ZILOG

UM009402-0201

5.13 IEEE 802.3 (ETHERNET) MODE

Z16C30 USC

USER'S MANUAL

Software can select this mode for the Transmitter and the Receiver, by programming 1001 into the TxMode and RxMode fields of the Channel Mode Register (CMR11-8 and CMR3-0).

The USC’s capabilities for handling Ethernet communications are less comprehensive than those offered by various dedicated Ethernet controllers. In particular, external hardware must detect collisions and generate the pseudorandom “backoff” timing when a collision occurs. In Ethernet parlance, blocks of consecutive characters are called "frames" rather than messages.

Since Ethernet is a relatively specific, well-defined protocol we can define the proper settings for many of the channel’s register fields and options. We can specify the exact values that software should program into the Transmit Mode Register (D70316) and Receive Mode Register (D60316). These values specify Bi-phase-Level encoding, a 32-bit CRC sent at End of Frame, no parity, and 8-bit characters, all according to Ethernet practise and IEEE

802.3. In addition the 2 LSBits specify auto-enabling based on signals from external hardware on /CTS and /DCD.

On the transmit side, software should program the TxPreL and TxPrePat fields of the Channel Control Register (CCR11-

8) to 1110. This value makes the Transmitter send the 64bit Preamble pattern 1010... before each frame. In 802.3 mode the Transmitter automatically changes the 64th bit from 0 to 1 to act as the “start bit”.

Furthermore, software should program the TxIdle field of the Transmit Command/Status Register (TCSR10-8) to 110 or 111. These values select an Idle line condition of constant Space or Mark. This condition, in turn, allows external logic to detect the missing clock transition in the first bit after the end of the CRC, and turn off its transmit line driver. (In a low-cost variant, such an Idle state can simply disable an open-collector or similar unipolar driver.) Another alternative is to use the Tx Complete output on /TxC to control the driver.

External logic must detect collisions that may occur while the channel is sending, and signal the Transmitter by driving the /CTS pin high when this occurs. Besides the auto-enable already noted for TMR1-0, software should write the CTSMode field of the Input/Output Control Register (IOCR15-14) as 0x to support this use of /CTS.

/DCD

RxD

Carrier

Detection

101010101 1

At least 58

Alternating Bits

Start Bit Carrier

Figure 5-7. Carrier Detection for a Received Ethernet Frame

16- or 48-Bit

Destination

Address

Source Address, Length,

Information

32-Bit

CRC

Loss

5-16

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

As in other synchronous modes, the MSBit of the TxSubMode field (CMR15) controls whether the Transmitter sends its accumulated CRC code if a Transmit Underrun condition occurs.

On the receive side, external logic should monitor the link and drive the /DCD pin low when it detects carrier. Figure 5-7 shows the relationship between an Ethernet frame on RxD and the signal on /DCD. Besides the auto-enable already noted for RMR1-0, software should program the DCDMode field of the Input/Output Control Register (IOCR13-12) as 01 to select the mode of the /DCD pin.

After /DCD goes low, the Receiver hardware hunts for 58 alternating bits of preamble, with the final 0 changed to a 1 as a “start bit”. When it finds this sequence it starts assembling data and may check the Destination Address in the frame as described below.

After a frame, the external hardware should drive /DCD high so that it sets up to the rising RxCLK edge after the one at which it samples the last bit of the CRC. In this mode and External Sync mode only among synchronous modes, if /DCD goes high while the Receiver is in the midst of assembling a character, it continues on to sample the remaining bits of the character and place the character in the RxFIFO.

The receiver marks the character that was partially or completely assembled when /DCD went high with RxBound status in the RxFIFO. As described in later sections, this

marking may set the channel’s Received Data Interrupt Pending bit and thus force an interrupt request on its /INT pin, and/or it may force a DMA request on the /RxREQ pin.

The LSBit of the RxSubMode field (CMR4) controls whether the Receiver checks an Address field at the start of each frame. If CMR4 is 0, the Receiver places all received frames in the RxFIFO and leaves address-checking to the software. (Some contexts call this “promiscuous mode”.) If CMR4 is 1, the Receiver compares the first two characters (16 bits) of each frame to the contents of the Receive Sync Register (RSR). It compares RSR0 to the first bit received, and RSR15 to the last bit, regardless of any “Select Serial Data MSB First” commands that the software may have written to the RTCmd field (CCAR15-11). The Receiver ignores the frame unless the address matches, or unless the first 16 bits are all ones, which indicates a frame that should be received by all stations. The Receiver places the address in the RxFIFO so that the software can differentiate “locally addressed” frames from “global” ones.

Except in the CRC, characters (“octets”) are sent LSBit first. The Length field that follows the Destination and Source Address fields is sent MSByte-first. IEEE 802.3 doesn’t include any other byte ordering information.

The USC doesn’t use the three LSBits of the TxSubMode field (CMR14-12) in 802.3 mode, nor the three MSBits of RxSubMode (CMR7-5), but Zilog reserves these bits for future enhancements. Software should always program them with zeroes in this mode.

UM97USC0100

5-17

ZILOG

UM009402-0201

5.14 HDLC/SDLC MODE

Z16C30 USC

USER'S MANUAL

Software can select this mode for both the Transmitter and the Receiver, by writing 0110 to the TxMode and RxMode in the Channel Mode Register (CMR11-8 and CMR3-0).

In some sense this is the most important mode of the USC, at least for new designs. It is similar to character-oriented synchronous modes in that data characters follow one another on the serial medium without any extra/overhead bits, and are organized into blocks of data with CRC checking applied to the block as a whole.

For HDLC and SDLC, the blocks of data are called "frames". Uniquely recognizable 8-bit sequences called "Flags", consisting of 01111110, precede and follow each frame. HDLC/SDLC protocols ensure the uniqueness of Flags, without imposing any restrictions on the data that can be transmitted, by having the Transmitter insert an extra 0 bit whenever the last six bits it has sent are 011111. A Receiver, in turn, removes such an inserted zero bit whenever it has sampled 0111110 in the last seven bit times.

Besides Flags, HDLC and SDLC define another uniquely recognizable bit sequence called an "Abort", consisting of a zero followed by seven or more consecutive ones. Depending on the exact dialect of HDLC or SDLC, and the security desired in communicating an Abort, software can program the Transmitter to send Aborts consisting of a zero followed by either 7 or 15 consecutive ones.

On the Transmit side, the two MSBits of the TxSubMode field (CMR15-14) control what the Transmitter does if a Transmit Underrun condition occurs, that is, if it needs another character to send but the TxFIFO is empty:

Flag of the next, into a single 8-bit instance. The same section also describes a feature whereby software can ensure that USCs manufactured after June 1993 send a programmable minimum number of Flags between frames.

Software can make the Transmitter send an Abort sequence at any time, by writing the “Send Abort” command to the TCmd field of the Transmit Command/Status Register (TCSR15-12). If CMR 15-14 as described above is 01, the Transmitter sends an extended Abort when software issues this command; otherwise it sends the shorter Abort sequence.

If CMR13 is 1, the Transmitter sends the Preamble sequence defined by the TxPreL and TxPrePat fields of the Channel Control Register (CCR11-8), before it sends the opening Flag of each frame.

If the TxIdle field (TCSR10-8) is 000 to select Flags as the idle line condition, CMR12 selects whether consecutive idle Flags share a single intervening 0. If CMR12 is 1, the idle pattern is 011111101111110..., while if CMR12 is 0 it is 0111111001111110... A Flag that opens or closes a frame never shares a zero with an idle-line Flag, even if CMR12 is 1.

On the Receive side, when the receiver detects the closing Flag of a frame, it marks the preceding (partial or complete) character with RxBound status in the RxFIFO. As described in later sections, this marking may set the channel’s Received Data Interrupt Pending bit and thus force an interrupt request on its /INT pin, and/or it may force a DMA request on the /RxREQ pin.

CMR15-14 Underrun Response

00 Send an Abort consisting of 01111111 01 Send an Abort consisting of a zero

followed by 15 consecutive ones 10 Send a Flag 11 Send the accumulated CRC followed

by a Flag, that is, make the data

transmitted so far into a proper frame.

After sending the sequence specified by this field, the Transmitter sends the next frame if software or the external Transmit DMA controller has placed new data in the TxFIFO. Otherwise it sends the Idle line condition specified by the TxIdle field of the Transmit Command/Status Register (TCSR10-8), as described later in 'Between Messages, Frames, or Characters'. That section also describes the conditions under which the Transmitter will combine the closing Flag of one frame, and the opening

5-18

The receiver automatically copes with single Flags between frames, and with shared zeroes between Flags, as described above for the transmit side.

5.14.1 Received Address and Control Field Handling

The RxSubMode field in the Channel Mode Register (CMR7-

4) determines how the Receiver processes the start of each frame, i.e., whether it handles Address and/or Control fields. To the extent that the Receiver handles Address or Control field(s), it always does so in multiples of 8 bits. Thereafter it divides data into characters of the length specified by the RxLength field of the Receive Mode Register (RMR4-2). The Receiver interprets this field as described below. (An “x” in a bit position means the bit doesn’t matter.)

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

CMR7-4 Address/Control Processing

xx00 The Receiver doesn’t handle the Address or Control

field. It simply divides all the data in all received frames into characters per RxLength and places it in the RxFIFO.

xx01 The Receiver checks the first 8 bits of each frame

as an address. If they are all ones or if they match the contents of the LSByte of the Receive Sync Register RSR7-0, the Receiver receives the frame into the RxFIFO, otherwise it ignores the frame through the next Flag. After placing the first 16 bits of the frame in the FIFO as two 8-bit bytes, it divides the rest of the frame into characters per RxLength.

x010 The Receiver checks an 8-bit address as described

above. If these bits are all ones or if they match RSR7-0, the Receiver places the first 24 bits of the frame in the RxFIFO as 3 8-bit bytes, before shifting to dividing characters according to RxLength.

x110 The Receiver checks an 8-bit address as described

above. If these bits are all ones or if they match RSR7-0, the Receiver places the first 32 bits of the frame in the RxFIFO as 4 8-bit bytes, before shifting to dividing characters according to RxLength.

CMR7-4 Address/Control Processing

1011 The Receiver processes an Extended Address as

described for 0011, and then an “Extended Control field”. If the first 8 bits of the address are all ones or if they match RSR 7-0, the Receiver places the next 8 bits after the extended address in the RxFIFO without examination. Then, as it stores each subsequent 8 bits in the RxFIFO, the Receiver checks the MSBit of the 8. If the MSBit is 1, it continues to receive more 8-bit bytes, through one that has its MSBit 0. Thereafter the Receiver places one more 8-bit byte into the RxFIFO, before shifting to dividing characters per RxLength.

1111 This mode differs from that described above for

1011 only in that the Receiver places the 16 bits after the extended address in the RxFIFO without examination, before starting to check MSBits for the end of the “extended Control field”.

Note that even though the Receiver can scan through an Extended Address, it will still only match its first byte. Note also that it matches RSR0 against the first bit received, and RSR7 against the last bit, regardless of whether software has written a “Select Serial Data MSB First” command to RTCmd (CCAR15-11).

0011 The Receiver processes an Extended Address at

the start of each frame. First it checks the first 8 bits of the frame as described above. If these bits are all ones or if they match RSR7-0, as the Receiver places each 8 bits of the address into the RxFIFO, it checks the LSBit of the 8. If the LSBit is 0, it goes on to put the next 8 bits into the RxFIFO as part of the address as well, through an address byte that has its LSBit 1. Then, the Receiver places the next 16 bits of the frame into the RxFIFO as two 8-bit bytes, before shifting to dividing characters according to RxLength.

0111 The Receiver processes an Extended Address as

described for 0011. If the first 8 bits of the address are all ones or if they match RSR7-0, the Receiver places the 24 bits after the extended address into the RxFIFO as 3 8-bit bytes, before shifting to dividing characters per RxLength.

If the RxSubMode field specifies some degree of Address and Control checking, that is, if it’s not xx00, and a frame ends before the end of the Address and possibly the Control field specified by the RxSubMode value, the Receiver sets a Short Frame bit in the status for the last character of the frame. This bit migrates through the RxFIFO with the last character, eventually appearing as the ShortF/CVType bit in the Receive Command/Status register (RCSR8). Note that this bit can represent the status at the time that an RxBound character was read from the RxFIFO, or the status of the oldest 1 or 2 characters that are still in the RxFIFO, as described in a later section, 'Status Reporting'. Note, however, that this length checking doesn’t report a problem if a frame ends within a CRC that follows an address and control field.

If RxLength (RMR4-2) is 000, specifying 8 bits per character, all RxSubMode (CMR7-4) values except xx00 are equivalent aside from short-frame checking.

UM97USC0100

5-19

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

5.14.2 Frame Length Residuals

The Receiver detects and strips inserted zeroes, Flags, and Aborts before any other processing, and doesn’t include these bits/sequences in the RxFIFO nor in CRC calculations. If the Receiver has assembled a partial character when it detects a Flag or Abort, it stores the partial character left-justified in an RxFIFO entry. (That is, in the MSBits of the byte regardless of RxLength.) The Receiver saves the number of bits received in this last byte in the RxResidue field of the Receive Command/Status Register (RCSR11-9). RxResidue remains available until the end of the next received frame. Software can use the Receive Status Block feature as described in a later section, to store the RCSR in memory after the frame. This reduces processing requirements still further.

Conversely, to send a frame that doesn’t contain an integral number of characters, software must ensure that the number of bits in the last character of the frame is written into the TxResidue field of the Channel Command/Status Register (CCSR4-2). This must happen before the Transmitter takes the last character out of the TxFIFO.

Figure 5-8 shows the CCSR. The Transmit Control Block feature can be used to set the TxResidue value for each block under DMA control, without the intervention of processor software. The active bits of a partial character must be right-justified, that is, they must be the LSBits of the last character. If the TxParEnab bit in the Transmit Command/ Status Register (TCSR5) is 1 specifying parity generation, for a partial character the Transmitter sends the parity bit after the number of bits specified by TxResidue, while in other characters the parity bit is the last one of the character length specified by TxLength (TMR4-2).

The encoding of RxResidue and TxResidue is as for RxLength and TxLength: 000 specifies that the last character contains eight bits, while 001-111 specify 1 to 7 bits respectively.

5.14.3 Handling a Received Abort

A USC manufactured after June 1993 reports a received Abort sequence in two different ways. The later section 'Status Handling' will note that a channel sets the Break/ Abort bit in the Receive Command/Status Register (RCSR5) when it recognizes an Abort sequence. This notification is not tied to a specific point in the received data stream.

The same section will also note that, if the QAbort bit in the Receive Mode Register (RMR8) is 1, USCs manufactured after June 1993 queue Abort conditions through the RxFIFO. From there, they eventually appear as the Abort/PE bit (RCSR2) of the last character of the frame — the one that has RxBound (RCSR4) set to 1. (If QAbort is 0 and parity checking is enabled, the channel uses this bit in the RxFIFO and RCSR to indicate Parity Errors.)

With a USC manufactured before June 1993, software can handle an Abort condition by enabling an interrupt when one is detected, and at that point forcing the receiver into Hunt mode for the next frame and ignoring/purging all received data. Or it can try examining received data (in memory for a DMA application or in the RxFIFO otherwise). Both an Abort and a closing Flag will terminate a frame with “RxBound” status; software can use the CRC error indication to differentiate Aborts from closing Flags.

With USCs manufactured after June 1993, software can handle Aborts more efficiently/elegantly by setting QAbort to 1 and using the Receive Status Block feature to store the RCSR status in memory for each frame, as described in the later section ‘Receive Status Blocks.’ Software can then examine this status word for each “frame”; any one that has Abort/PE set isn’t a proper frame in that it ended with an Abort sequence rather than a Flag.

5-20

UM97USC0100

ZILOG

UM009402-0201

5.15 HDLC/SDLC LOOP MODE

Z16C30 USC

USER'S MANUAL

This mode applies only to the Transmitter. Software can select it by programming the TxMode field of the Channel Mode Register (CMR11-8) as 1110 while programming the RxMode field (CMR3-0) as 0110 to select HDLC/SDLC mode.

Loop mode is useful in networks in which the nodes or stations form a physical loop. Except for one station that acts in a “Primary” or Supervisory role, each must pass the data it receives from the “preceding” station to the “following” one. The only time that a secondary station can break out of this echoing mode is when it receives a special sequence called a “Go Ahead” and it has something to send.

Again, this is a specific protocol and we can define how certain other register fields should be programmed for its intended application. For IBM SDLC Loop compatibility, software should program the Transmit Mode Register (TMR) as 670216. This enables the Transmitter with NRZISpace encoding, 16-bit CCITT CRC, no parity, and 8-bit characters. Software also should program the TxIdle field in the Transmit Command/Status Register (TCSR10-8) as 000 to select Flags as the idle line state.

The two MSBits of the TxSubMode field (CMR15-14) control what the Transmitter does if an Underrun condition occurs, that is, if it needs a character to send but the TxFIFO is empty. The available choices are similar to those in normal HDLC/SDLC mode but the Transmitter has a wider range of subsequent actions:

CMR15-14 Response to Underrun

00 The Transmitter sends an Abort (“Go

Ahead”) sequence consisting of a zero followed by seven consecutive ones, and then stops sending and reverts to echoing the data it receives. Zilog doesn’t recommend this option in IBM SDLC Loop applications because only the Primary station should issue a “Go Ahead” sequence (and it should be in regular HDLC/SDLC mode).

01 Like 00 except that the Abort includes 15

ones.

10 The Transmitter sends Flags on an

Underrun, until another frame is ready or until software clears CMR13 to 0.

11 The Transmitter sends its accumulated CRC

followed by Flags on an Underrun, until another frame is ready to transmit or until software clears CMR13 to 0. Zilog doesn’t recommend this option either, because the frame format probably hasn’t been met when there’s an underrun.

The CMR13 bit plays a different role when the Transmitter is first being enabled to “insert this station into the loop”, as compared to normal operation after that. Before software programs the Channel Mode Register for SDLC Loop mode and enables the Transmitter, the TxD pin carries continuous Ones. If software initially enables the Transmitter with CMR13 0, it continues to output Ones on TxD. When CMR13 is 1 after software first enables the Transmitter, the channel sends Zeroes on TxD until the Receiver detects a “Go Ahead” sequence (01111111). At this point the channel starts passing data from RxD to TxD with a 4bit delay, and sets the OnLoop bit in the Channel Command/Status Register (CCSR7; see Figure 5-8).

RCCF

Ovflo

RCCF

Avail

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

Clear

RCCF

UM97USC0100

DPLL

Sync

DPLL 2Miss

DPLL

1Miss

DPLLEdge

Loop

Send

Resrvd

Figure 5-8. The Channel Command/Status Register (CCSR)

TxResidue

/TxACK /RxACK

5-21

ZILOG

UM009402-0201

5.15 HDLC/SDLC LOOP MODE (Continued)

Z16C30 USC

USER'S MANUAL

OnLoop stays 1 unless the part is reset or software programs the TxMode field to a different value. Once OnLoop is 1 and the channel is repeating data from RxD to TxD, CMR13 controls what the Transmitter does when it receives a(nother) Go Ahead sequence. If CMR13 is 0, the channel just keeps repeating data, including the “GA”. If CMR13 is 1 when the Receiver detects another “Go Ahead”, the Transmitter changes the last bit of the GA from 1 to 0 (making it a Flag), sets the LoopSend bit (CCSR6) and proceeds to start sending data. (If there’s no data available in the TxFIFO it keeps sending Flags, otherwise it sends the data in the TxFIFO.)

5.16 CYCLIC REDUNDANCY CHECKING (CRC)

A USC channel will send and check CRC codes only in synchronous modes, namely External Sync, Monosync, Slaved Monosync, Bisync, Transparent Bisync, HDLC/ SDLC, HDLC/SDLC Loop, and 802.3 modes.

The TxCRCType and RxCRCType fields in the Transmit and Receive Mode Registers (TMR12-11 and RMR12-11) control how the Transmitter and Receiver accumulate CRC codes.

00 in either field selects the 16-bit CRC-CCITT polynomial x15+x12+x5+1. In HDLC, HDLC Loop, and 802.3 modes, the Transmitter inverts each CRC before sending it, the Receiver checks for remainders of F0B816, and the TxCRCStart and RxCRCStart bits should be programmed as 1 to start the CRC generators with all ones. In other synchronous modes the Transmitter sends accumulated CRCs normally and the Receiver checks for all-zero remainders.

01 in either field selects the CRC-16 polynomial x16+ x15+x2+1. The Transmitter sends accumulated CRCs normally and the Receiver checks for all-zero remainders. This choice is not compatible with HDLC, HDLC Loop, and

802.3 protocols, and in these modes CRC-16 will not operate correctly even between USC family Transmitters and Receivers.

10 in TxCRCType or RxCRCType selects the 32-bit Ethernet polynomial x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x +x4+x2+x+1. In HDLC, HDLC Loop, and 802.3 modes, the Transmitter inverts each CRC before transmitting it, the Receiver checks for remainders equal to C704DD7B16, and the TxCRCStart and RxCRCStart bits should be programmed as 1 to start the CRC generators with all ones. In other synchronous modes the Transmitter sends CRCs normally and the Receiver checks for all-zero remainders.

When the Transmitter has been sending data and encounters either a character marked as “EOF/EOM”, or an underrun condition when CMR15=1, CMR13 determines how it proceeds. If CMR13 is 1 in either of these situations, the Transmitter stays active and sends Flags or additional frames as they become available in the TxFIFO. If CMR13 is 0 after the channel has sent a closing Flag or an idle Flag, it clears the LoopSend (CCSR6) bit and returns to repeating data from RxD onto TxD.

CMR12 controls whether the Transmitter sends idle Flags with shared zero bits, as described for normal HDLC/ SDLC mode.

Zilog reserves the value 11 in TxCRCType or RxCRCType for future product enhancements; it should not be programmed.

The TxCRCStart and RxCRCStart bits (TMR10 and RMR10) control the starting value of the Transmit and Receive CRC generators for each frame or message. A 0 in this bit selects an all-zero starting value and a 1 selects a value of all ones. In HDLC, HDLC Loop, and 802.3 modes these bits should be 1.

The Transmitter and Receiver automatically clear their CRC generators to the state selected by these CRCStart bits at the start of each frame. The Transmitter does this after it sends an opening Sync or Flag sequence. The Receiver does so each time it recognizes a Sync or Flag sequence (it may be the last one before the first character of the frame or message). For special CRC requirements, the Clear Rx CRC and Clear Tx CRC commands give software the ability to clear the CRC generators at any time. See the later section 'Commands' for a full description of these operations.

The TMR10 and RMR10 bits (TMR9 and RMR9) control whether the channel processes transmitted and received characters through the respective CRC generators. A 0 excludes characters from the CRC while a 1 includes them. The Transmitter captures the state of TxCRCEnab with each character as it’s written into the TxFIFO, so that software can change the bit dynamically for different characters.

5-22

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

If the TxCRCatEnd bit (TMR8) is 1 and the TxMode field (CMR11-8) specifies a synchronous mode, the Transmitter sends the contents of its CRC generator after sending a character marked as EOF/EOM. If TxCRCatEnd is 0 the Transmitter doesn’t send a CRC after such a character. (A character can be marked as EOF/EOM if software writes a command to the Transmit Command/Status Register (TCSR), or when software or an external Transmit DMA controller writes one or two characters to the TxFIFO so that the Transmit Character Counter decrements to zero.) Whether or not it sends a CRC, the Transmitter then sends a Sync or Flag sequence, depending on the protocol.

In synchronous modes, the MS 1 or 2 bits of the TxSubMode field (CMR15 and in some modes also CMR14) control whether the Transmitter sends the contents of its CRC generator if it encounters a Transmit Underrun condition, namely if it needs a character to send but the TxFIFO is empty. Whether or not it sends a CRC, the Transmitter then sends a Sync or Flag sequence, depending on the protocol.

On the receive side, in synchronous modes other than HDLC/SDLC, HDLC/SDLC Loop, and 802.3, there’s a two character delay between the time a Receiver places each received character in the RxFIFO and when it processes (or doesn’t process) the character through the CRC generator. Therefore, software can examine each received character and set RxCRCEnab appropriately to exclude certain characters from CRC checking, if it can do so before the next one arrives. A Receiver doesn’t introduce this delay in HDLC/SDLC, HDLC/SDLC Loop, or 802.3 mode, because in these modes all characters in each frame should be included in the CRC calculation.

Figure 5-9 shows how a Receiver routes data to the Receive CRC generator differently in HDLC/SDLC, HDLC/ SDLC Loop, and 802.3 modes than in other synchronous modes. In the former three modes, the Receiver shifts each bit from RxD into the CRC generator when it shifts the bit into its main shift register. In other sync modes, the Receiver passes the data through a second shift register located between the main shift register and the CRC generator. This second shift register is effectively (RxLength) bits long, and gives the software time to decide whether to include each received character in the CRC calculation.

The Receive CRC generator constantly checks whether its contents are “correct” according to the kind of CRC specified by the RxCRCType field (RMR12-11). In some modes this simply means whether it contains an all-zero value. The CRC generator provides a corresponding Error output that the Receiver captures in the RxFIFO with each received character. This bit migrates through the RxFIFO with each character and eventually appears as the CRCE/ FE bit in the Receive Command/Status Register (RCSR3). Software should ignore this bit for all characters except the one associated with the end of each message or frame (it’s almost always 1).

The CRCE bit that’s important is the one that reflects the output of the CRC generator after the Receiver has shifted the last bit of the CRC into it. But the operating difference described above affects which character this bit is associated with. The Receiver always places the CRC code itself in the RxFIFO; if RxLength calls for 8-bit characters the CRC represents either 2 or 4 characters. In HDLC/ SDLC or 802.3 mode, the CRCE bit associated with the last character of the CRC is the one that shows the CRCcorrectness of the frame. But in the other synchronous modes, the CRCE bit of interest is the one with the second character after the last character of the CRC. This means that the Receive Status Block feature can’t be used to capture the CRC correctness of received messages in Transparent Bisync mode.

Note that the CRCE/FE bit can represent the status at the time that an RxBound character was read from the RxFIFO, or the status of the oldest 1 or 2 characters that are still in the RxFIFO, as described later in 'Status Reporting'.

Because the Receiver places all the bits of each received CRC in the RxFIFO, a USC channel can be used for CRCpass-through applications. This is not true of all serial controllers.

UM97USC0100

5-23

ZILOG

UM009402-0201

5.16 CYCLIC REDUNDANCY CHECKING (Continued)

Data In

RxFIFO

Z16C30 USC

USER'S MANUAL

SI SO

U X

Used in HDLC/SDLC

and 802.3 Modes

(RxLength)-bit

Shift Register

(RxLength)-bit

Shift Register

Rx CRC

Generator

Used in all

other Sync modes

Err

M U

5-24

Flag/Abort

RxD

Detect Logic,

Incl. Shift Register

Used in HDLC/

SDLC Mode

Figure 5-9. A Model of the Receive Datapath

UM97USC0100

ZILOG

UM009402-0201

5.17 PARITY CHECKING

Z16C30 USC

USER'S MANUAL

A USC channel can handle a Parity bit in each character in either asynchronous or synchronous modes, although many synchronous protocols use CRC checking only.

If the TxParEnab bit in the Transmit Mode Register (TMR5) is 1, the Transmitter creates a parity bit as specified by the TxParType field (TMR7-6) and sends it with each character. Similarly, if the RxParEnab bit (RMR5) is 1, the Receiver checks a parity bit in each received character, according to the RxParType field (RMR7-6). A channel interprets TxParType and RxParType as follows:

xMR7-6 Type of Parity

00 Even 01 Odd 10 Zero 11 One

For unencoded data, 10/Zero is the same as “Space parity” and 11/One is the same as “Mark parity”.

TxParEnab and TxParType are “global states” in that a channel doesn’t carry these bits through the TxFIFO with each character.

In asynchronous modes, the Transmitter and Receiver handle the parity bit as an additional bit after the number of bits specified by the TxLength and RxLength fields (TMR4-2 and RMR4-2). In synchronous modes they handle the parity bit as the last (most significant) bit of that number. The Receiver includes a parity bit in the data characters in the RxFIFO and Receive Data Register (RDR), except in asynchronous modes with 8-bit data.

In HDLC/SDLC protocols, a USC Receiver can queue either a Parity Error or an Abort indication through the RxFIFO, but not both. Regardless of the protocol, in order to have the Receiver check parity, the QAbort bit in the Receive Mode Register (RMR8) must be 0.

If QAbort is 0, RxParEnab is 1, and the Receiver finds that the parity bit of a received character is not as specified by RxParType, it sets a Parity Error bit. This bit accompanies the character through the RxFIFO, eventually appearing as the Abort/PE bit in the Receive Command/Status Register (RCSR2). The Abort/PE bit can represent a latched interrupt bit, or the status at the time that an RxBound character was read from the RxFIFO, or the status of the oldest 1 or 2 characters that are still in the RxFIFO, as described in the next section.

UM97USC0100

5-25

ZILOG

UM009402-0201

5.18 STATUS REPORTING

Z16C30 USC

USER'S MANUAL

The most important status reported by the Transmitter and Receiver is available in the LSBytes of the Transmit and Receive Command/Status Registers (TCSR and RCSR). Figures 5-11 and 5-12 show the format of these registers. It will be helpful to describe some common characteristics of these status bits before discussing each individually.

When software writes and reads transmit and received data directly to and from a serial controller, it can read and write status and control registers as needed to handle the overall communications process. But with the USC, external DMA controllers often handle the data without software/ processor intervention. Because of this, software needs other means of controlling the transmit and receive processes and tracking their status. These means include the Transmit and Receive Character Counters and the Transmit Control Block and Receive Status Block features. Later sections describe these features in considerable detail. For now we just note that Receive Status Blocks allow the Receive DMA controller to store a version of the RCSR in memory with the received data. Such stored status differs slightly from the status in the RCSR.

Software can program a channel to assert its Interrupt Request output (/INTA or /INTB) based on certain bits in the TCSR and RCSR. Chapter 7 covers interrupts in detail; for now we’ll just note that a channel typically sets one of these bits when a specified event occurs or a specified condition starts. Such a bit typically remains 1 until host software clears or “unlatches” it by writing a 1 to it. This means that a channel won’t request another interrupt for the same condition until software has written a 1 to the bit. For the two interrupts that reflect the start of an ongoing condition, IdleRcved and the “break” sense of Break/ Abort, the Receiver doesn’t clear the RCSR bit until the software has written a 1 to unlatch the bit, and the condition has ended.

Five of the bits in the RCSR (ShortF/CVType, RxBound, CRCE/FE, Abort/PE, and RxOver) are associated with particular received characters. The Receiver queues these bits through the RxFIFO with the characters. The corresponding bits in the RCSR may reflect the status of the oldest character(s) in the FIFO, or that of the character last read out of the FIFO, as described in the next few paragraphs.

Note that it’s essential for software to keep WordStatus in the right state, when changing the IA bits in the LSbyte of the RICR, or when writing DMA or interrupt threshold values to the MSbyte.

The RxBound, Abort/PE, and RxOver bits actually operate differently in the RCSR depending on whether software has enabled each to act as a source of interrupts. If the Interrupt Arm (IA) bit in the Receive Interrupt Control Register (RICR) for one of these bits is 1, the channel sets the RCSR bit to 1 when a character having the subject status becomes the oldest one in the RxFIFO, or the second-oldest with WordStatus=1. Once one of these bits is 1, it stays that way until software writes a 1 to it. (The channel doesn’t actually set the Receive Status IP bit to request an interrupt for one of these bits, until software or the Receive DMA controller reads the associated character from RDR.)

For ShortF/CVType and CRCE/FE, and for RxBound, Abort/ PE, and RxOver when the associated IA bit is 0, if the last time that software or an external Receive DMA controller read this channel’s RxFIFO via the RDR, the channel provided a character marked with RxBound status, then these RCSR bits reflect the status of that character. This is true only until software reads the (MSByte of the) RCSR, or a Receive DMA controller stores it in the Receive Status Block, or until software or the Receive DMA controller reads RDR again.

For ShortF/CVType and CRCE/FE, and for RxBound, Abort/PE, and RxOver when the associated IA bit is 0, if the last time that software or the Receive DMA controller read the RxFIFO via the RDR, the character returned (both of the characters returned) had RxBound=0, or if software has read the (MSByte of the) RCSR or the Receive DMA controller has stored it in a Receive Status Block since the last time either one read the RDR, then the RCSR bit reflects the status of the oldest character(s) in the RxFIFO (if any). In this latter case, if the RxFIFO is empty the status bit is not defined. If the WordStatus bit is 1 in the Receive Interrupt Control Register (RICR3) and there are two or more characters in the FIFO, the status bit is the inclusive OR of the status of the oldest two characters in the FIFO. Otherwise the bit reflects the status of the oldest character in the FIFO.

In order for these queued interrupt features to operate properly, software should set the WordStatus bit in the Receive Interrupt Control Register (RICR3) to 1 before it (or the Rx DMA channel) reads data from the RxFIFO/RDR 16 bits at a time, and to 0 before it (or the RxDMA channel) reads data 8 bits at a time.

5-26

Just in case that wasn’t perfectly clear, the flowchart of Figure 5-10 presents the same information.

UM97USC0100

ZILOG

UM009402-0201

Start for RxBound,

Abort/PE, or RxOver:

What's the

corresponding IA

bit in the RICR?

Z16C30 USC

USER'S MANUAL

Provide the state of a latch that's set when a character

with this condition becomes

the oldest in the RxFIFO

(or the 2nd-oldest with

WordStatus=1), and is cleared

when SW writes a 1 to this bit

Did the last read

from the RDR have

RxBound=1?

(The bit is not

defined!)

Start for ShortFrame/

CVType or CRCE/FE:

Yes No

None

Has the (MSByte

of the) RCSR been

read since then?

Yes

How many

characters are in

the RxFIFO??

One

Two or

Provide the saved

status of the

RxBound character

What's the

WordStatus bit

(RICR3)?

Figure 5-10. How a USC Channel Provides the “Queued” Status Bits in the RCSR

UM97USC0100

Provide the status of

the oldest character

in the RxFIFO

Provide the inclusive

OR of the status of the

two oldest characters

in the RxFIFO

5-27

ZILOG

UM009402-0201

5.18 STATUS REPORTING (Continued)

Z16C30 USC

USER'S MANUAL

TCmd

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

Under

Wait

Txidle

Figure 5-11. The Transmit Command/Status Register (TCSR)

5.18.1 Detailed Status in the TCSR

PreSent: The Transmitter sets this bit (TCSR7) in a syn-

chronous mode, when it has finished sending the Preamble specified in the TxPreL and TxPrePat fields of the Channel Control Register (CCR). A channel can request an interrupt when this bit goes from 0 to 1 if the PreSent IA bit in the Transmit Interrupt Control Register (TICR7) is 1. Software must write a 1 to PreSent to unlatch and clear it, and to allow further interrupts if TICR7 is 1; writing a 0 to PreSent has no effect. See the later section 'Between Frames, Messages, or Characters' for more information on Preambles.

IdleSent: The Transmitter sets this bit (TCSR6) in any mode, when it has finished sending “one unit” of the Idle line condition specified in the TxIdle field in the MSByte of this TCSR. If the Idle condition is Syncs or Flags as described later in 'Between Frames, Messages, or Characters', the unit is one character or sequence and the flag and interrupt can recur for each one sent. For any other Idle condition, the Transmitter sets the flag and interrupt only once, when it has sent the first bit of the condition. The channel can request an interrupt when this bit goes from 0 to 1 if the IdleSent IA bit in the Transmit Interrupt Control Register (TICR6) is 1. Software must write a 1 to IdleSent to unlatch and clear it, and to allow further interrupts if TICR6 is 1; writing a 0 to IdleSent has no effect.

AbortSent: The Transmitter sets this bit (TCSR5) in HDLC/SDLC or HDLC/SDLC Loop mode, when it has finished sending an Abort sequence. A channel can request an interrupt when this bit goes from 0 to 1 if the AbortSent IA bit in the Transmit Interrupt Control Register (TICR5) is 1. Software must write a 1 to AbortSent to unlatch and clear it, and to allow further interrupts if TICR5 is 1; writing a 0 to AbortSent has no effect. See the earlier sections 'HDLC/SDLC Mode' and 'HDLC/SDLC Loop Mode' for more information on Abort sequences.

Pre

Sent

Idle

Sent

Abort

Sent

EOF/ EOM

Sent

CRC Sent

All

SentTxUnderTxEmpty

EOF/EOM Sent: The Transmitter sets this bit (TCSR4) in a synchronous mode, when it has finished sending a closing Flag or Sync sequence. A channel can request an interrupt when this bit goes from 0 to 1 if the EOF/EOM Sent IA bit in the Transmit Interrupt Control Register (TICR4) is 1. Software must write a 1 to EOF/EOM Sent to unlatch and clear it, and to allow further interrupts if TICR4 is 1; writing a 0 has no effect. See the later section 'Between Frames, Messages, or Characters' for more information on closing Flags and Syncs.

CRCSent: The Transmitter sets this bit (TCSR3) in a synchronous mode, when it has finished sending a Cyclic Redundancy Check sequence. A channel can request an interrupt when this bit goes from 0 to 1 if the CRC Sent IA bit in the Transmit Interrupt Control Register (TICR3) is 1. Software must write a 1 to CRCSent to unlatch and clear it, and to allow further interrupts if TICR3 is 1; writing a 0 to CRCSent has no effect. See the section 'Cyclic Redundancy Checking' for more information on CRC’s.

AllSent: This read-only bit (TCSR2) is 0 in asynchronous modes, while the Transmitter is sending a character. Software can use this bit to figure out when the last character of an async transmission has made it out onto TxD, before changing the mode of the Transmitter.

TxUnder: The Transmitter sets this bit (TCSR1) in any mode, when it needs another character to send but the TxFIFO is empty. It does this even in asynchronous modes. A channel can request an interrupt when this bit goes from 0 to 1 if the TxUnder IA bit in the Transmit Interrupt Control Register (TICR1) is 1. The Transmitter sets TxUnder one or two clocks before the current character is completely sent on TxD. See 'Handling Overruns and Underruns' later in this chapter for further details on how to handle this condition.

TxEmpty: This read-only bit (TCSR0) is 1 when the TxFIFO is empty, and 0 when it contains one or more characters.

5-28

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

RCmd(WO)

2ndBE 1stBE

14 13 12 11 10 9 8 7 6 5 4 3 2 1 015

RxResidue

ShortF/

CVType

Figure 5-12. The Receive Command/Status Register (RCSR)

5.18.2 Detailed Status in the RCSR

2ndBE: The USC sets this read-only bit (RCSR15) to 1

when software or an external Receive DMA controller reads data from the RDR, there are two or more characters in the RxFIFO, and the Receiver marked the second-oldest one with one or more of RxBound, Abort/PE, or Rx Overrun status. (The bit’s name stands for Second Byte Exception.) A channel clears this bit to 0 when software or the Receive DMA controller reads data from the RxFIFO/RDR, there are two or more characters in the RxFIFO, and the Receiver didn’t mark the second-oldest one with any of these three conditions. If software or the Receive DMA controller reads data from the RDR when there’s only one character in it, this bit is undefined until the next time one of them reads RDR.

1stBE: The USC sets the read-only bit (RCSR14) to 1 when software or an external Receive DMA controller reads data from the RDR, and the Receiver marked the oldest character read with one or more of RxBound, Abort/PE, or Rx Overrun status. (The bit’s name stands for First Byte Exception.) A channel clears this bit to 0 when software or the Receive DMA controller reads data from the RDR, and the Receiver didn’t mark the oldest character with any of these three conditions.

ShortF/CVType: The Receiver queues this bit through the RxFIFO with each character. RCSR8 may reflect the status at the time that an RxBound character was read from the RxFIFO, or the status associated with the oldest 1 or 2 character(s) still in the RxFIFO, as described earlier in this Status Reporting section. In a stored Receive Status Block it always represents the status of the preceding RxBound character.

This bit will be 1 only in HDLC/SDLC and only for characters that the Receiver also marks with RxBound=1. When the RxSubMode field (CMR7-4) specifies Address and possibly Control field processing in HDLC/SDLC mode, the Receiver sets this bit for the last character of a frame if it hasn’t come to the end of the specified field(s) by the end of the frame.

Exited

Hunt

Idle

Rcved

Break /AbortRxBound

CRCE

/FE

Abort

/PERXOverRxAvail

ExitedHunt: The Receiver sets this bit (RCSR7) in any mode, when it leaves its Hunt state. In Async modes this happens right after software enables the Receiver. In External Sync mode, the Receiver leaves Hunt state when the Enable/Sync signal on /DCD goes from high to low. In Monosync, Bisync, or Transparent Bisync mode the Receiver leaves Hunt state when it recognizes a Sync sequence. In HDLC/SDLC mode the Receiver leaves Hunt state when it recognizes a Flag. In 802.3 (Ethernet) mode, if software has enabled address checking the Receiver leaves Hunt state when it matches the Address at the start of a frame, otherwise it does so after detecting the start bit at the end of the Preamble.

A channel can request an interrupt when this bit goes from 0 to 1 if the ExitedHunt IA bit in the Receive Interrupt Control Register (RICR7) is 1. Software must write a 1 to ExitedHunt to unlatch and clear it, and allow further interrupts if RICR7 is 1; writing a 0 to ExitedHunt has no effect.

IdleRcved: The Receiver sets this bit (RCSR6) when it samples RxD as one for 15 consecutive RxCLKs in HDLC/SDLC mode, or for 16 consecutive RxCLKs in any other mode. A channel can request an interrupt when this bit goes from 0 to 1 if the IdleRcved IA bit in the Receive Interrupt Control Register (RICR6) is 1. Software must write a 1 to IdleRcved to unlatch it, and to allow further interrupts if RICR6 is 1; writing a 0 has no effect. A channel doesn’t actually clear RCSR6 until software has written a 1 to unlatch it, and RxD has gone to 0 to end the idle condition. (IdleRcved isn’t useful in Async modes that use a 16x, 32x, or 64x clock. In these cases keep RICR6=0 to avoid interrupts, and ignore RCSR6.)

Break/Abort: The Receiver sets this bit (RCSR5) in an asynchronous mode when it detects a Break condition, that is, when it samples the Stop bit of a character as 0, and all the preceding data bits (and the parity bit if any) have also been 0. It sets the bit in HDLC/SDLC mode when it detects seven consecutive ones, i.e., an Abort or Go Ahead sequence.

UM97USC0100

5-29

ZILOG

UM009402-0201

5.18 STATUS REPORTING (Continued)

Z16C30 USC

USER'S MANUAL

This bit is not associated with a particular point in the received data stream, for either the Break or Abort condition. (But see the description of “Abort/PE” below for an Abort indication that is queued with Receive data.)

A channel can request an interrupt when this bit goes from 0 to 1 if the Break/Abort IA bit in the Receive Interrupt Control Register (RICR5) is 1. Software must write a 1 to Break/Abort to unlatch it, and to allow further interrupts if RICR5 is 1; writing a 0 has no effect. In async modes, a channel doesn’t actually clear RCSR5 until software has written a 1 to unlatch it, and RxD has gone to 1 to end the break condition.

RxBound: The Receiver queues this bit through the RxFIFO with each received character. It sets the bit with a character that represents the boundary of a logical grouping of data, but this indication isn’t visible to software until the character is the oldest one in the RxFIFO, or the secondoldest with WordStatus=1.

As described earlier in this Status Reporting section, RCSR4 may represent an interrupt bit, or the status associated with the oldest 1 or 2 character(s) still in the RxFIFO; or may be 1 if a RxBound character was just read from the RxFIFO. Since the Receive Status Block feature stores the RCSR in memory after each character that the Receiver marks with this bit set, a Receive Status Block always shows RxBound as 1.

In HDLC/SDLC mode the Receiver sets RxBound for the last complete or partial character before an ending Flag or Abort. In Transparent Bisync mode it sets this bit for an ENQ, EOT, ETB, ETX, or ITB character that follows a DLE. In External Sync or 802.3 (Ethernet) mode the Receiver sets this bit for the character just completed or partially assembled when the /DCD pin went High. In Nine-Bit mode it sets this bit for an address character. Note that the Receiver never sets this bit in other modes, including Monosync and Bisync modes.

A channel can request an interrupt when software or a DMA channel reads a character from the RDR that has this bit set, if the RxBound IA bit in the Receive Interrupt Control Register (RICR4) is 1. In this case software must write a 1 to RxBound to unlatch it and allow further interrupts; writing a 0 has no effect.

CRCE/FE: The Receiver queues this bit through the RxFIFO with each received character. RCSR3 may represent the status at the time that a RxBound character was read from the RxFIFO, or the status associated with the oldest 1 or 2 character(s) still in the RxFIFO, as described earlier in this Status Reporting section. In a stored Receive Status Block it represents the status of the previous character, which in turn represents the CRC-correctness of the frame in 802.3 and HDLC/SDLC modes.

In synchronous modes the Receiver makes CRCE/FE 0 if its CRC checker showed “correct” status when it stored the character in the RxFIFO, or 1 if the CRC checker wasn’t correct. See the earlier section Cyclic Redundancy Checking for more information. In asynchronous, isochronous, or Nine-Bit mode, the Receiver makes this bit 1 to show a Framing Error if it samples the associated character’s Stop bit as 0.

Abort/PE: The Receiver queues this bit through the RxFIFO with each received character. RCSR2 may represent an interrupt bit, or the status at the time that a RxBound character was read from the RxFIFO, or the status associated with the oldest 1 or 2 character(s) still in the RxFIFO, as described earlier in this Status Reporting section. In a stored Receive Status Block it may represent an interrupt bit or the status of the previous 1 or 2 character(s).

If the QAbort bit in the Receive Mode Register (RMR8) is 0, the Receiver sets this bit to show a Parity Error for a character if the RxParEnab bit (RMR5) is 1 and the character’s parity bit doesn’t match the condition specified by the RxParType field. See the earlier section 'Parity Checking' for more information.

In HDLC/SDLC mode with the QAbort bit 1, the Receiver sets this bit (along with RxBound) for a character that was followed by an Abort sequence.

A channel can request an interrupt when software or a DMA channel reads a character from the RDR that has this bit set, if the Abort/PE IA bit in the Receive Interrupt Control Register (RICR2) is 1. In this case software must write a 1 to Abort/PE to unlatch it and allow further interrupts; writing a 0 to RCSR2 has no effect.

5-30

UM97USC0100

ZILOG

UM009402-0201

Z16C30 USC

USER'S MANUAL

RxOver: The Receiver queues this bit through the RxFIFO

with each received character. It sets the bit to indicate a Receive FIFO overrun, but the overrun isn’t visible to software until the character that caused it is the oldest one in the RxFIFO, or the second-oldest with WordStatus=1.

As described earlier in this Status Reporting section, RCSR1 may represent an interrupt bit, or the status at the time a RxBound character was read from the RxFIFO, or the status associated with the oldest 1 or 2 character(s) still in the RxFIFO. In a stored Receive Status Block this bit may represent an interrupt bit or the status of the previous character.

5.19 DMA SUPPORT FEATURES

When software writes and reads all the data to and from a serial controller, it can maintain its own counters and length-tracking mechanisms, and can use them to tell when to read status and issue commands. But in DMA applications we would like to “decouple” the processor and its software from such intimate and real-time involvement with the transmit and receive processes. This is only possible if we include features in the serial and/or DMA controllers, by which software can figure out the length and correctness of frames or messages long after they’re received, and by which the hardware can change parameters and save status information at appropriate points with as little processor software involvement as possible.

The USC features that support such operation include the Receive and Transmit Character Counters, the RCC FIFO that stores the length of received frames, the Transmit Control Block feature that allows software to include control information with transmit data in Transmit DMA buffers, and the Receive Status Block feature that stores status with received data in Receive DMA buffers. The following subsections describe these features.

5.19.1 The Character Counters

The Transmitter includes a 16-bit Transmit Character Counter (TCC) that software can use to control the length of transmitted frames and messages in DMA applications. The Receiver includes a similar Receive Character Counter (RCC) that software can use to record and save the length of frames and messages in DMA applications. Software can also use the RCC to cause an interrupt if a frame exceeds a certain length.

The Receiver sets this bit to 1 for the first character for which there was no room, which is held in a holding register between the shifter and the RxFIFO. Once this happens, the Receiver doesn’t store any more received characters in the RxFIFO, until software responds as described in ‘Handling Overruns and Underruns’ later in this chapter.

A channel can request an interrupt when software or a DMA channel reads a character from the RDR that has this bit set, if the RxOver IA bit in the Receive Interrupt Control Register (RICR1) is 1. In this case, software must write a 1 to RxOver to unlatch it and allow further interrupts; writing a 0 has no effect.

RxAvail: This read-only bit (RCSR0) is 1 if the RxFIFO contains 1 or more characters, or 0 if it’s empty.

While most of this section describes these features in terms of the length of frames and messages in synchronous protocols, they may be useful in asynchronous work as well.

Figures 5-13 and 5-14 show the structure of the TCC and RCC features, respectively. Software can write the 16-bit Transmit Count Limit Register (TCLR) at any time, to define the length of the next transmitted message(s) or frame(s). Similarly, it can write the 16-bit Receive Count Limit Register (RCLR) at any time, to define the length of future received messages and frames at which the Receiver will interrupt. Software can also use the Transmit Control Block feature to make a channel automatically fetch a new value for the TCLR and TCC from memory before each block of characters. The TCLR and RCLR can be read back at any time. A channel never changes their values except to clear them to zero at reset time, and when it loads TCLR from a 32-bit Transmit Control Block.

Writing the TCLR or RCLR doesn’t have any immediate effect on the TCC or RCC feature. Only when one of several events occurs does a channel load the value from TCLR or RCLR into the actual 16-bit character counter. If the value in TCLR or RCLR is zero at that time, the channel disables the TCC or RCC feature, while if the value is nonzero it enables the feature.

UM97USC0100

5-31

ZILOG

UM009402-0201

5.19 DMA SUPPORT FEATURES (Continued)

Z16C30 USC

USER'S MANUAL

A channel loads the value from the TCLR into the Transmit Character Counter, and enables or disables the TCC accordingly, when one of the following occurs:

1. Software writes the Trigger Tx DMA (or Trigger Tx and

Rx DMA) command to the RTCmd field of the Channel Command/Address Register (CCAR15-11), or

2. Software writes the Load TCC (or Load RCC and TCC)

command to RTCmd in the CCAR, or

3. Software writes the Purge Tx FIFO (or Purge Tx and Rx

FIFO) command to RTCmd in CCAR, or

4. The TxCtrlBlk field in the Channel Control Register

(CCR15-14) is 10, specifying a two-word Transmit Control Block, and an external Transmit DMA controller fetches (the second byte of) the second word containing the new character count. Which is to say, the channel fetches the count “through” the TCLR.

A channel loads the value from the RCLR into the Receive Character Counter, and enables or disables the RCC feature, when any of the following occur:

1. Software writes the Trigger Rx DMA (or Trigger Tx and

Rx DMA) command to the RTCmd field of the Channel Command/Address Register (CCAR15-11), or

2. Software writes the Load RCC (or Load RCC and TCC)

command to RTCmd in the CCAR, or

3. Software writes the Purge Rx FIFO (or Purge Tx and Rx

FIFO) command to RTCmd in CCAR, or

4. The Receiver detects an opening Flag or Sync charac-

ter.

Once a channel has loaded the TCC or RCC with a nonzero value (which enables the feature) it decrements the counter for each character/byte written into the associated FIFO. That is, the Transmitter decrements the TCC by 1 or 2 when software or an external Transmit DMA controller loads transmit data into the TxFIFO. The Receiver decrements the RCC by 1 for each character/byte that it transfers from its shift register into the RxFIFO.

A non-zero TCLR value should represent the number of characters to send, not including any Transmit Control Block information, nor a CRC that the Transmitter gener-

ates. A non-zero RCLR value can be either all ones, or the number of characters/bytes in a message or frame above which the Receiver should interrupt, including any CRC but not including any Receive Status Block information. For frame or message-oriented applications in which there’s no particular maximum received frame or message length, the all-ones value simplifies computing the length of each frame or message slightly. This value allows software to obtain the frame length by simply ones-complementing the value read from RCCR or from a Receive Status Block in memory, rather than by subtracting it from the starting value.

On the Transmit side, software can read the value in the TCC at any time from the Transmit Character Count Register (TCCR), but writing the TCCR address has no effect. Figure 5-14 shows a decoder that detects when the counter contains 0001. When software or an external Transmit DMA controller writes enough data into the TxFIFO so that the TCC counts down to 0, the channel marks the character that corresponds to decrementing from 1 to 0 as End of Frame/End of Message. When this character gets to the other end of the FIFO, the marking makes the Transmitter conclude the frame appropriately. (Typically, it sends a CRC and a closing Flag or Sync character after the marked character.)

If software or an external Transmit DMA controller writes 16 bits to the TDR while the counter contains 0001, the channel only puts the character on the D7-0 lines into the TxFIFO — it ignores the data on D15-8. In a system in which even-addressed bytes fall on D7-0 (e.g., a system based on an Intel processor) this isn’t a problem. On the other hand, in systems in which even-addressed bytes reside on D15-8 (e.g., a system based on the Zilog Z8000 or 16C0x or a Motorola 680x0) it can cause problems. In such systems, if the last character of a frame falls at an even address, software must copy the last character into the subsequent odd address as well, before presenting the buffer to the Transmit DMA controller.

The Transmitter suppresses its DMA request from the time an external Transmit DMA controller places the EOF/EOM character in the TxFIFO until the Transmitter sends it. When software uses the Transmit Control Block feature, this procedure ensures that the Transmit DMA controller doesn’t load the control information for the next frame or message, while the Transmitter still needs the values for the current one.

5-32

UM97USC0100

ZILOG

UM009402-0201

D15-D0

(See Text)

TCLR

Counter (TCCR)

Non-Zero

Detect

Enable TCC

USER'S MANUAL

(From

Command-

Driven Logic)

Z16C30 USC

Write

TDR

0001

Detect

Figure 5-13. A Model of the Transmit Character Counter Feature

EOF/

EOM

TxFIFO

UM97USC0100

5-33

Zilog Z16C30 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual