ICs for Communications
Multichannel Network Interface Controller for HDLC
MUNICH32
PEB 20320 Version 3.4
User’s Ma nual 01. 200 0 DS3
•
For questions on technology, delivery and prices please contact the Infineon Technologies Offices
in Germany or the Infineon Technologies Companies and Representatives worldwide:
see our webpage at http://www.infineon.com
•
PEB 20320
Revision History: Current Version: 01.2000
Previous Version: User’s Manual 1998-06-01 DS2 (V3.4)
Page
(in previous
Version)
Page
(in current
Version)
Subjects (major changes since last revision)
Package P-TQFP-176-1 removed from User’s Manual.
Edition 01.2000
Published by Infineon Technologies AG,
SC,
Balanstraße 73,
81541 München
© Infineon Technologies AG 2000.
All Rights Reserved.
Atten tio n pl e ase !
As far as patents or other rights of third parties are concerned, liability is only assumed for components, not for
applications, processes and circuits implemented within components or assemblies.
The information describes the type of component and shall not be considered as assured characteristics.
Terms of delivery and rights to change design reserved.
Due to technical requirements components may contain dangerous substances. For information on the types in
question please contact your nearest Infineon Technologies Office.
Infineon Technologies AG is an approved CECC manufacturer.
Packing
Please use the recycling operators known to you. We can also help you – get in touch with your nearest sales
office. By agreement we will take packing material back, if it is sorted. You must bear the costs of transport.
For packing material that is returned to us unsorted or which we are not obliged to accept, we shall have to invoice
you for any costs incurred.
Components used in life-support devices or systems must be expressly authorized for such purpose!
Critical components1 of the Infineon Technologies AG, may only be used in life-support devices or systems2 with
the express written approval of the Infineon Technologies AG.
1 A critical component is a component used in a life-support device or system whose failure can reasonably be
expected to cause the failure of that life-support device or system, or to affect its safety or effectiveness of that
device or system.
2 Life support devices or systems are intended (a) to be implanted in the human body, or (b) to support and/or
maintain and sustain human life. If they fail, it is reasonable to assume that the health of the user may be en-
dangered.
ABM®, AOP®, ARCOFI®, ARCOFI®-BA, ARCOFI®-SP, DigiTape®, EPIC®-1, EPIC ®-S , ELIC®, FALC®54, FALC®56,
FALC®-E1, FALC ®-LH, IDEC®, IOM®, IOM®-1, IOM®-2, IPAT®-2, ISAC ®-P, ISAC®-S, ISAC®-S TE, ISAC®-P TE,
ITAC®, IWE®, MUSAC®-A, OCTAT®-P, QUAT®-S, SICAT®, SICOFI®, SICOFI®-2, SICOFI®-4, SICOFI®-4µC,
SLICOFI® are registered trademarks of Infineon Technologies AG.
ACE™, ASM™, ASP™, POTSWIRE™, QuadFALC™, SCOUT™ are trademarks of Infineon Technologies AG.
PEB 20320
User’s Manual 3 01.2000
Preface
The Mult ich ann el Network Inte rfac e Con trol ler fo r H DLC (MUN ICH 32 ) is a Mu lti cha nne l
Protocol Controller for a wide area of telecommunication and data communication
applications.
Organization of this Document
This User’s Manual is divided into 9 chapters. It is organized as follows:
•Chapter 1, Introduc tio n
Gives a general description of the product and its family, lists the key features, and
presents some typical applications.
•Chapter 2, Functional Description
This cha pter pro vides a deta iled d escripti on of th e inte rfaces and th e protoc ol mo des.
•Chapter 3, Operational Description
Provides a description of MUNICH32 reset procedure and initialization.
•Chapter 4, Detailed Register Description
Gives a detailed description of the shared memory organization.
•Chapter 5, Application Notes
•Chapter 6, Application Hints
•Chapter 7, Electrical Characteristics
Gives a detailed description of all electrical DC and AC characteristics and provides
timing diagrams and values for all interfaces.
•Chapter 8, Package Outlines
•Chapter 9, Appendi x
This chapter provides source code ex amples.
Your Comments
We welcome your comments on this document as we are continuously aiming at
improving our documentation. Please send your remarks and suggestions by e-mail to
sc.docu_comments@infineon.com
Please provide in the subject of your e-mail:
device name (MUNICH32), device number (PEB 20320), device version (Version 3.4),
and in the body of your e-mail:
document type (User’s Manual), issue date (01.2000) and document revision number
(DS3).
PEB 20320
User’s Manual 4 01.2000
PEB 20320
Table of Contents Page
User’s Manual 5 01.2000
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
1.2 Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
1.3 Pin Definitions and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
1.4 Logic Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
1.5 Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
1.6 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
2 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1 Serial Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
2.2 Microprocessor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
2.2.1 Intel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
2.2.2 Motorola Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.3 DMA Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
2.3 Basic Functional Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
2.4 Detailed Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
2.5 Boundary Scan Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
3 Operational Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 31
3.1 Reset State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
3.2 Initialization Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
4 Detailed Register Descripti on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
4.1 Organization of the Shared Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
4.2 Control and Configuration Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
4.2.1 Action Specification (Read Once After Each Action Request Pulse) . . .136
4.2.2 Interrupt Queue Specification . . . . . . . . . . . . . . . . . . . . . . .140
4.2.3 Interrupt Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
4.2.4 Time Slot Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
4.2.5 Channel Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
4.2.6 Current Receive and Transmit Descriptor Address . . . . . . . . . . . . . . 1 61
4.3 Transmit Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
4.4 Receive Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
5 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 73
5.1 Test Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 73
5.1.1 Test Loop Definitions for the MUNICH32 . . . . . . . . . . . . . . . . . . . . . . .173
5.1.1.1 Internal Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
5.1.1.2 Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
5.1.1.3 External Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
5.1.1.4 External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
5.1.2 Test Loop Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
5.1.3 Test Loop Deactivation and Switching . . . . . . . . . . . . . . . . . . . . . . . . . .176
5.1.3.1 Software Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
PEB 20320
Table of Contents Page
User’s Manual 6 01.2000
5.1.3.2 Hardware Reset Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
5.1.4 Test Loop Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
5.1.4.1 Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
5.1.4.2 External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
5.2 MUNICH32 in a LAN/WAN Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
5.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
5.2.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
5.2.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
5.2.3.1 Device Driver Module MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . .191
5.2.3.2 Application Module MROUTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
5.2.4 Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
5.2.5 Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
5.2.6 Adaption of the 68040 µP Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
5.2.7 Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
5.3 Memory Bus Occupancy for a Single MUNICH32 . . . . . . . . . . . . . . . . . . .214
5.3.1 Bus Occupancy Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
5.3.2 Bus Occupancy for Idle Tx Channels . . . . . . . . . . . . . . . . . . . . . . . . . .218
6 Application Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
6.1 Frequency Adaption in an Intel 368 Common Bus System . . . . . . . . . . . .220
6.2 MUNICH32 Memory Space Requirement . . . . . . . . . . . . . . . . . . . . . . . . .223
6.3 Serial Interface to different PCM Systems . . . . . . . . . . . . . . . . . . . . . . . . .224
6.3.1 MUNICH32 for SIEMENS Primary Access Interface . . . . . . . . . . . . . . .224
6.3.2 MUNICH32 in Systems with MITEL ST BUS . . . . . . . . . . . . . . . . . . . . .227
7 Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
7.1 Absolute Maximum Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
7.2 DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
7.3 Capacitances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
7.4 AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
7.5 Microprocessor Interface Intel Bus Mode . . . . . . . . . . . . . . . . . . . . . . . . .2 32
7.6 Microprocessor Interface Motorola Bus Mode . . . . . . . . . . . . . . . . . . . . . .235
8 Package Outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
9.1 Source Code Extract MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
9.2 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
PEB 20320
Introduction
User’s Manual 7 01.2000
1 Introduction
The Multi ch ann el Netw ork Inte rfac e Con trol ler fo r HDL C (MUNI CH32 ) is a Mu ltic ha nne l
Protocol C ontrolle r, which han dles up to 32 data c hannels o f a full dup lex PCM hig hway.
It performs layer 2 HDLC formatting/deformatting or V.110 and X.30 protocols up to
a network data rate of 38.4 Kbit/s as well as transparent transmission for the
DMI mode 0, 1 and 2. The processed data is passed on to an external memory shared
with one or more host processors.
MUNICH32 is compatible with the LAPD ISDN (Integrated Services Digital Network)
protocol specified by CCITT as well as with HDLC, SDLC, LAPB DMI protocols. It
provides any rate adaption for time slot transmission data rate from 64 Kbit/s down to
8 Kbit/s and the concatenation of any time slots to data channels, supporting the ISDN
H0, H11, H12 superchannels.
Due to the se functio ns the MUN ICH32 can be used in a wide area of tele commun ication
and data communication applications, e.g. in central office switches, for the connection
of a d igi tal PABX to a h ost com pu ter, a s a ce ntra l D-chann el c ontro ll er to 32 ISDN ba si c
access D-channels or as a multiplexer for terminals and other peripherals. Up to
4 MUNICH32s can be connected to one PCM highway, so a D-channel controller with
128 channels can be achieved.
P-MQFP-160-1
User’s Manual 8 01.2000
Multichannel Network Interface Controller for HDLC
MUNICH32 PEB 20320
Version 3.4 CMOS
Type Package
PEB 20320 P-MQFP-160-1
1.1 Features
•Serial Interfac e
–Up to 32 independent communication channels.
–Serial multiplexed (full duplex) input/output for
2048-, 4096-, 1544- or 1536-Kbit/s PCM
highways.
•Dynamic Programmable Channel Allocation
–Compatible with T1/DS1 24-channel and CEPT
32-channel PCM byte format.
–Concatenation of any, not necessarily consecutive, time slots to superchannels
independently for receive and transmit direction.
–Support of H0, H11, H12 ISDN-channels.
–Subchanneling on each time slot possible.
•Bit Processor Functions (adjustable for each channel)
–HDLC Protocol
–Automatic flag detection and transmission
– Shared opening and closing flag
– Detection of interframe-time-fill change, generation of
interframe-time-fill ‘1’s or flags
–Zero bit insertion
–Flag stuffing and flag adjustment for rate adaption
–CRC generation and ch ec king (16 or 32 bits)
–Transparent CRC option per channel and/or per message
–Error detection (abort, long frame, CRC error, 2 categories
of short frames, non-octet frame content)
–Special short frame mode to allow reception of ‘frames’ with a least on byte
length
–ABORT/IDLE gen erat ion
PEB 20320
Introduction
User’s Manual 9 01.2000
–V.110/X.30 Protocol
–Automatic synchronization in receive direction, automatic generation of
the synchronization pattern in transmit direction
–E / S / X bits freely programmable in transmit direction, van be changed
during transmission; changes monitored and reported in receive direction
–Generation/detection of loss of synchronism
–Bit framing with network data rates from 600 bit/s up to 38.4 Kbit/s
–Transparent Mode A
–Slot synchronous transparent transmission/reception without frame structure
–Bit-overwrite with fill/mask bits
–Flag generation, flag stuffing, flag extraction, flag generation
in the ab ort case with programmabl e flag
–Transparent Mode B
–Transparent transmission/reception in frames delimited by 00H flag s
–Shared opening and closing flag
–Flag stuffing, flag detection, flag generation in the abort case
–Error detection (non octet frame content, short frame, long frame)
–Transparent Mode R
–Transparent transmission/reception with GSM 08.60 frame structure
–Automatic 0000H flag generation/detection
–Support of 40, 391/2, 401/2 octet frames
–Error detection (non octet frame content, short frame, long frame)
–Protocol Independent
–Channel inversion (data, flags, IDLE code)
–Format conventions as in CCITT Q.921 § 2.8
–Data over- and underflow detected
•Processor Interface
–ON-CHIP 64-channel DMA controller with buffer chaining capability.
–Compatible with Motorola 68020 processor family and
Intel 32-bit processor (80386).
–32 bit dat a bus and 32 bit address bus (4 Gbyte RAM addressable, Motorola and
Intel non-parity) or 28 bit address bus (256 Mbyte RAM addressable, Intel parity)
–Intel parity mode with data byte parity (4 parity bits)
–Parity check for read accesses
–Parity generat ion for write accesses
–Interrupt-circular buffer with variable size
–Maskable interrupts for each channel
–µP interface buffer of depth 16 long words for adaptive bus occupation
PEB 20320
Introduction
User’s Manual 10 01.2000
•General
–Connection of up to four MUNICH32 supporting a
128-channel basic access D-channel controller.
–ON-CHIP receive and transmit data buffer; the buffer size is 256 bytes each.
–HDLC protocol or transparent mode, support of ECMA 102, CCITT I4.63 RA2,
V.110, X.30, DMI mode 0, 1, 2 (bit rate adaption), GSM 08.60 TRAU frames.
–LOOP mode, complete loop as well as single channel loop
–JTAG boundary scan test
–Advanced low -p ow er CMOS tech nol ogy
–TTL-compatible inputs/outputs
–160 pin P-MQFP package
PEB 20320
Introduction
User’s Manual 11 01.2000
1.2 Pin Configuration
(top view)
Figure 1
ITP03487
Marking
A19
A9
D8
D18
A18
D17
A12
A11
D10
A10
D9
A8
INT/INT
D31
A28/DP0
D28
D27
A27
V
SS
RSP
RDATA
CI0
I/M
READY/DSACK
HLDA/BG
BGACK/PM
HOLD/BR
DS/PCHK
W,R/R;W
D30
A30/DP2
A26
D26
D25
D21
A21
D20
A20
Index
D19
D16
D15
A22
V
SS
D29
D3
D4
SS
V
D7
D0
D1
BE0
D2
A3
A4
D5
A5
D6
BE1
A7
A17
A15
A14
D14
A13
D13
D11
BE2
B16
BERR
AR
TSP
TCLK
N.C.
HLDAO/BGO
TEST
SCLK
RESET
JTEST3
JTEST2
JTEST0
JTEST1
N.C.
RCLK
CI1
CI3
CI4
N.C.
MUNICH32
PEB 20320
V
SS
V
DD
D22
SS
V
SS
V
V
DD
D23
A23
D24
A24
V
SS
V
DD
A25
V
SS
V
DD
V
SS
V
DD
A29/DP1
V
SS
V
DD
A31/DP3
A16
D12
V
DD
V
SS
V
DD
A6
V
DD
V
SS
V
SS
V
DD
V
V
SS
SS
A2
V
DD
V
SS
V
DD
V
SS
BE3
V
DD
V
SS
V
SS
ADS/AS
V
DD
V
SS
N.C.
N.C.
CI2
TDATA
N.C.
N.C.
V
SS
V
DD
1
160
150
140
130
121
10 20 30 4041
50
60
70
80
100120 110 8190
V
SS
V
SS
V
DD
V
SS
DD
V
DD
V
DD
V
V
DD
SS
V
V
V
SS
DD
V
V
SS
DD
DD
V
SS
V
SS
V
DD
V
V
SS
V
V
DD
SS
P-MQFP-160-1
PEB 20320
Introduction
User’s Manual 12 01.2000
1.3 Pin Definitions and Func tions
Pin Definitions and Functions
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
83, 87, 88, 92,
97, 103, 104,
110, 111, 117,
123, 130, 136,
141, 144, 150,
151, 157, 3, 9,
10, 16, 22, 23,
29, 30, 36, 59,
62, 64, 77
VSS IGround (0 V)
All pins m ust have the same level.
73 I/M I Intel Bus Mode or Motorola Bus Mode
By connec tin g th is pin to ei the r VSS or VDD
the bus interface can be adapted to either
Intel or Moto rola enviro nment. The da ta is
interpreted either in Intel or Motorola
manner; i .e. litt le or big e ndian co nvention .
I/M = low: Intel bus mode
I/M = high: Motorola bus mode
39 A31
DP3
O
I/O
Address Bit 31
(Intel non-parity/Motorola) tristate when
unused.
Data Parity 3 (Intel parity mode),
bidirectional tristate line containing/
expecting parity bit of D(31:24).
35 A30
DP2
O
I/O
Address Bit 30
(Intel non-parity/Motorola) tristate when
unused.
Data Parity 2 (Intel parity mode),
bidirectional tristate line containing/
expecting parity bit of D(23:16).
Note: Input pins that are unused in a specific configuration must be strapped to VSS.
I/O or output pins that are unused in a specific configuration must be left open!
PEB 20320
Introduction
User’s Manual 13 01.2000
33 A29
DP1
O
I/O
Address Bit 29
(Intel non-parity/Motorola) tristate when
unused.
Data Parity 1 (Intel parity mode),
bidirectional tristate line containing/
expecting parity bit of D(15: 8)
28 A28
DP0
O
I/O
Address Bit 28
(Intel non-parity/Motorola) tristate when
unused
Data Parity 0 (Intel parity mode),
bidirectional tristate line containing/
expecting parity bit of D(7:0)
26, 21, 19, 15,
13, 8, 6, 2, 160,
156, 154, 149,
147, 143, 139,
135, 133, 128,
126, 122, 120,
116, 114, 109,
107, 102
A(27:2) O Address Bus
tristate when unused.
91, 94, 96, 100 BE(3:0) O Byte Enable (Intel bus mode)
The MUNICH32 provides word and long
word transfer. The byte enables determine
the address offset to the address
A31 …A2, the actual word has been
stored to.
Address Offset Size (Motorola mode)
Indicates the number of bytes remaining to
be transferred for this access. These
signals define the active sections of the
data bus.
In both cases these signals are tristate
when unused.
See Chapter 2.2 for details.
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 14 01.2000
38, 34, 32, 27,
25, 20, 18, 14,
12, 7, 5, 1, 159,
153, 148, 146,
142, 138, 134,
132, 127, 125,
121, 119, 115,
113, 108, 106,
101, 99, 95
D(31:0) I/O Data Bus
The data bus lines are bidirectional tristate
li nes which interface wi th the system’s
data bus.
86 DS
PCHK
O
O
Data Strobe (Motorola mode)
This signal indicates that valid data is to be
placed on th e data bus (read cyc le) or has
been placed on the data bus by the
MUNICH32 (write cycle).
Parity Check (Intel parity mode)
This signal indicates, whether the parity
bits of a read cycle are valid (PCHK high)
or invalid (PCHK low). See Chapter 2.2.1
for details.
84, 93, 89, 98,
105, 112, 118,
124, 129, 131,
137, 140, 145,
152,158, 4,11,
17, 24, 31, 37,
57, 58, 63, 78
VDD ISupply voltage 5 V ± 5%
All pins m ust have the same level.
85 ADS
AS
O
O
Address Status (Intel bus mode)
This signal indicates that a valid bus cycle
defini tio n an d ad dre ss are b ein g driven a t
the pins.
Address Strobe (Motorola bus mode)
A valid address is transm itte d on the
address bus at the falling edge of AS.
In both cases this signal is active low and
tristate when unused.
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 15 01.2000
90 W/R
R/W
O
O
Write/Read (Intel bus mode)
This signal distinguishes write from read
operations.
Read/Write (Mo toro la bus mode )
This signal distinguishes between read
and write operations.
In both cases this signal is tristate when
unused.
75 READY
DSACK
I
I
Ready (Intel bus mode)
This signal indicates that the current bus
cycle is complete. When READY is
asserted duri ng a read cy cl e the
MUNICH32 latches the input data and
terminates the cycle. When READY is
asserted during a write cycle the
MUNICH32 terminates the cycle.
Data Transfer Acknowled ge (Motorola
bus mode)
This active low input indicates that a data
transfer m ay b e perf orm ed. D uri ng a rea d
cycle data becomes valid at the falling
edge of DSACK. The data is latched
internally and the bus c yc le i s t erm ina ted .
During a write cycle the falling edge of
DSACK marks the latching of data and the
bus cycle is terminated.
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 16 01.2000
76 BERR IBus Error (Intel and Motorola bus mode)
This active low signal informs the
MUNICH32 that a bus cycle error has
occurred. The MU NICH 32 ter minates the
bus cycle.
In case of an erroneous read cycle in the
control and configuration section an
‘Action Request Fail’ interrupt is generated
and the ac tion is sus pended. In case o f an
erroneous read cycle in the tran sm it data
section the corresponding frame is
aborted and a FO interrupt is generated. In
all other cases of read or write cycles
terminated with an error condition no
further actions are performed by the
MUNICH32. Please see Chapter 2.2,
‘Microprocessor Interface’, first para graph
and Figure 18.
As bus cycles are executed without time
limit this signal prevents a hang-up
sit uation o f the MUNI CH32.
74 B16 I Word Operation
Setting this bit to VDD ca use s the
MUNICH32 to perform 32-bit long word
access es to t he sha red memo ry, set tin g it
to VSS causes the MUNICH32 to perform
16-bit word accesses on the data lines
D(15:0) only. In 16-bit word access mode
the data lines D(31:16) should be left
open.
This bit is not dynamic and should be set
to VDD in Intel parity mode.
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 17 01.2000
82 HOLD
BR
O
I/O
Bus Hold Request (Intel bus mode)
This signal is driven high when the
MUNICH32 requests the control of the
bus.
Bus Request (Motorola bus mode)
This signal is driven low when the
MUNICH32 requests the control of the bus
and is interpreted when another
MUNICH32 wants to be the bus master.
79 HLDA
BG
I
I
Bus Hold Acknowledge (Inte l b us m ode )
This active high signal indicates that the
processor has released the control of the
bus. The MUNICH32 starts the bus cycles.
Bus Grant (Motorola bus mode)
This active low signal indicates that the
MUNICH32 may assume the bus
mastership.
81 BGACK
PM
I/O
I
Bus Grant Acknowledge (Motorola bus
mode)
This signal is driven low by the device,
when it has become the bus master. It also
informs the MUNICH32 whether another
device is bus master.
Parity Mode (Intel bus mode)
This signal has to be strapped to VDD
before reset to enable the Intel parity
mode or to VSS before reset to enable the
Intel non-parity mode. It has to be left
strapped during reset and operation.
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 18 01.2000
80 HLDAO
BGO
O
O
Bus Hold Acknowledge Passing ON
(Intel bus mode)
If another MUNICH32 has initiated a
HOLD REQUEST the HOLD
ACKNOWLEDGE is passed on via
HLDAO. The MUNICH32 does not give
another HOLD REQUEST before the
HOLD ACKNOWLEDGE has been
deact ivated in ord er to prevent b locking i n
the case of continuous request by one
MUNICH32.
Bus Grant Acknowledge (Motorola bus
mode)
If the MUNICH32 has not requested the
bus mastership it passes on the BUS
GRANT. The MUNICH32 does not give
another BUS REQUEST before the BUS
REQUEST and the BUS GRANT
ACKNOWLEDGE have been deactivated
in order to prevent blocking in the case of
continuous request by one MUNICH32.
66 AR IAction Request
AR must be pulsed low to cau se an act ion
of the MUNICH32. T he AR is acti vated for
updating the mode and channel
configurations, setting a test loop, or
initializing the interrupt queue. The
min. time between Reset and first AR is
500 µs.
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 19 01.2000
40 INT/INT OInterrupt Request
An interrupt is given when a transmission/
reception error is detected, frames are
received or tra nsm it ted , or a h os t in itia ted
action is performed. The interrupt pulse
signal interacts with a write cycle to the
shared memory. The data written into the
interrupt queue contains the interrupt
specification.
The interrupt is active high for Intel bus
mode and active low for Motorola bus
mode.
44 RCLK I Receive Clock
This clock provides the data clock for RDA
T1/DS1 24-channel 1.544 MHz
24-channel 1.536 MHz
CEPT 32-channel 2.048 MHz
32-channel 4.096 MHz
45 RSP I Receive Synchronization Pulse
This signal provides the reference for the
receive PCM frame synchronization. It
marks the first bit in the PCM f ram e.
46 RDATA I Receive Data
Serial data is received at this PCM input
port. The MUNICH32 supports the T1/
DS1 24-channel PCM format, the CEPT
32-channel PCM format as well as a 32-
channel PC M form at with 4.096 -Mb it/s bit
rate.
61 SCLK I System Clock
PCM highway system clock highway
frequency
32-channe l 16.384 MH z 2.048 or
4.096 MHz
24-channe l 12.288 MH z 1.536 MHz
24-channe l 12.352 MH z 1.544 MHz
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 20 01.2000
51 …47 CI(4:0) I Chip Identification
Up to four MUNICH32 can be connected
to the PCM highway. These inputs define
the start address of the control section
pointer in the shared memory.
CI4 is the polarity of A31 …A22
CI3 is the polarity of A21 …A16
CI2 is the polarity of A15 …A4
CI1 is the polarity of A3
CI0 is the polarity of A2
A1, A0 are always ‘00’
56 …53 JTEST
(3:0) I/O Test Pins
The MUNICH32 supports the JTAG
boundary scan test and the JTAG test
standards.
65 TEST I Test
If this bit is set to VDD MUNICH32 works in
a test mode.
For the functional working mode this bit
must be set to VSS.
67 TDATA O Transmit Data
Serial data is sent by thi s PCM output port
is push-pull for active bits in the PCM
frame and tristate for inactive bits.
68 TSP I Transmit Synchronizati on Pulse
This signal provides the reference for the
transmit frame synchronization. It marks
the last bit in the PCM frame.
69 TCLK I Transmit Clock
This clock provides the data clock for
TDATA
T1/DS1 24-channel 1.544 MHz
24-channel 1.536 MHz
CEPT 32-channel 2.048 MHz
32-channel 4.096 MHz
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 21 01.2000
60 RESET I Reset
41, 42, 43, 52,
70, 71, 72 N.C. - No Connect
These pins are reserved and should not be
connected
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1 Symbol Input (I)
Output (O) Function
PEB 20320
Introduction
User’s Manual 22 01.2000
1.4 Logic Symbol
Figure 2
MUNICH32 Logic Symbol
ITL03488
Serial
Interface
(3:0)
BE
1)
A31/DP3, A30/DP2, A29/DP1, A28/DP0, A[27:2]
(31:0)D
30
32
RCLK
RSP
RDATA
TCLK
TSP
TDATA
I/M
W/R R/W
ADS/AS
DS/PCHK
READY/DSACK
BERR
B16
HOLD/BR
HLDA/BG
BGACK/PM
HLDAO/BGO
AR
INT/INT
5 (4:0)CI
4TEST
JTEST (3:0)
RESET
SCLK
V
DD
VSS
Interface
System
Bus
Microprocessor
Interface
MUNICH32
PEB 20320
1)
PEB 20320
Introduction
User’s Manual 23 01.2000
1.5 Functional Block Diagram
Figure 3
Block Diagram of MUNICH32
ITB03495
BE (3:0) A (31:2) D (31:0)
32
RCLK RSP RDATA
TCLK TSP TDATA
I/M
W/R
ADS DS READY/ BERR B16
HOLD/ HLDA/ HLDAO/ AR
INT/
CI (4:0)
4
TEST
JTEST
RESET
BGACK
AS DSACK BR
R/W BG BGO INT
SCLK
5
Microprocessor Bus Interface
Serial Interface/Formatter Controller Unit
CSR
Configuration and
State RAM
CM
DMA Controller
Formatter
Transmit
TF
TB
Transmit Buffer
Deformatter
Receive
RD
Receive Buffer
RB
CD
MI
/PM
PEB 20320
Introduction
User’s Manual 24 01.2000
The internal functions of MUNICH32 are partitioned into 8 major blocks.
1. Serial Interface, Formatter Control Unit CD
– Parallel-Serial conversion, PCM timing, switching of the test loops, controlling of the
multiplex procedure.
2. Tr ansm it Formatter TF
– HDLC frame, bit stuffing, flag generation, flag stuffing and adjustment,
CRC generation, transparent mode transmission and V.110, X.30 80 bit framing.
3. Transmit Buffer TB
– Buffer size of 64 long words allocated to the channels, i.e. eight PCM frames can be
stored before transmission, individual channel capacity programmable.
4. Receive Deformat ter RD
– HDLC frame, zero-bit deletion, flag detection, CRC checking, transparent mode
reception and V.110, X.30 80 bit framing.
5. Receive Buffer RB
– Buffer size of 64 long words allocated to the channels, i.e. eight PCM frames can be
stored, individual long words are freely accessible by each channel.
6. Configuration and State RAM CSR
– Since the Trans mit Formatter, Receive Deformatter are used in a multiple x manner,
the state and configuration information of each channel has to be stored.
7. DMA Controller CM
– Interrupt processing, memory address calculation, chaining list handling,
chip configuration.
8. µP interface MI
– Motorola/Intel microprocessor interface.
PEB 20320
Introduction
User’s Manual 25 01.2000
1.6 System Integratio n
The MUNICH32 is designed to handle up to 32 data channels of a PCM highway. It
transfers the data between the PCM highway and a memory shared with a host
proce ssor via a 32 -bit µP interfa ce. At the s ame time it pe rforms protoc ol form atting an d
deformat ting as w ell as rate a daption for each c hannel indepe ndentl y. The hos t sets the
operating mode, bit rate adaption method and time slot allocation of each channel by
writing the information into the shared memory.
Using subchanneling each time slot can be shared between up to four MUNICH32s; so
that in o ne single time slot four diffe rent D-channels can be handled by fo ur MUNICH32s.
Figure 4, Figure 5 and Figure 6 give a general overview of system integration of the
MUNICH32.
Figure 4
General System Integration (Intel Bus Mode)
ITS03489
MUNICH32
0
HLDA
1
MUNICH32
HLDA
MUNICH32
2
HLDA
3
MUNICH32
HLDA
CPU
Optional
System Bus
Up to 4
MUNICH32
PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s)
CPU
Memory
HOLD
HLDA
HOLD
HLDA
HLDAO
HOLD
HLDAO
HLDA
HOLD
HLDAO
HLDA
HOLD
HLDA
PEB 20320
Introduction
User’s Manual 26 01.2000
Figure 5
General System Interface (Intel Bus Mode)
Figure 6
General System Interface (Motorola Bus Mode)
ITS03490
MUNICH32 MUNICH32
Memory
CPU
System Bus
PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s)
HOLD
HLDA
HOLD
HLDA
HLDAO
ITS03491
MUNICH32 MUNICH32 CPU
Optional
System Bus
Up to 4
MUNICH32
PCM Highway
CPU
Memory
BR
BG
BGACK
BGACK
BG
BR
PEB 20320
Introduction
User’s Manual 27 01.2000
MUNICH32’s bus interface consists of a 32 bit bidirectional data bus (D31 …D0), 32/28
Address lines (A31 …A2, BE3 …BE0) or (A27 …A2, BE3 …BE0), four data byte
parity lines DP(3:0), five lines (W/R/R/W, ADS/AS, DS /PCHK, BERR READY/DSACK)
to control and monitor the bus cycle, one action request and one Interrupt line.
The system bus allocation is controlled by the four signals (HOLD/BR, HLDA/BG,
BGACK, HLDAO/BGO). A mode pin allows the bus interface to be configured for either
Intel or Motorola mod e. An o peration mode pin B16 e nab les the transfer of a 32 bi t long
word in two co nsec utive 16 bit wor d operations.
Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11 illustrate how the MUNICH32
may be used in dif ferent applicati ons, like i n a Primary Rate In terface, a R outer, a Pack et
Switch and a Central D-Channel Handler, as part of an ISDN switching system.
Figure 7
Architecture of a Primary Access Board
ITS07372
Host Interface
(Alternative B)
System Bus
Local CPU Bus
CPU (Alternative A)
INT/INT
AR
PCM
System
Interface
CPU Bus Arbitration
2254
FALC54
PEB Controller
Interrupt Memory
System
System Bus
Controller
Interface
Line
T1/S2 Line
20320
MUNICH32
PEB Host Interface
PEB 20320
Introduction
User’s Manual 28 01.2000
Figure 8
Architecture of a Central D-Channel Handler
ITS04829
EPIC
PEB 2056 Interrupt
Controller HSCX
SAB 82525
System Bus
Controller
System Bus
CPU
PEB 20320
MUNICH32
INT/INT
AR
PCM
System
Interface
Local CPU Bus
CPU Bus Arbitration
Memory
System
Signaling Highway
PCM Highway
(Alternative B)
Host Interface
(Alternative A)
R
Host Interface
PEB 20320
Introduction
User’s Manual 29 01.2000
Figure 9
Architecture of a Packet Switch/Router
ITS07374
Controller
System Bus
System Bus
CPU
INT/INT
AR
PCM
System
Interface
Local CPU Bus
CPU Bus Arbitration
Memory
Line Driver
V.24, V.21, V.35, ...
2254
FALC54
PEB
Interrupt System
Controller
Interface
Line
T1/S2 Line
20320
MUNICH32
PEB
SAB 82538
ESCC8
PEB 20320
Introduction
User’s Manual 30 01.2000
Figure 10
MUNICH32 in a System with a RISC CPU
Note: To reduce complexity the host interface is not explicitly shown here.
ITS07371
Interrupt
Controller System
Memory
System Bus
Controller
System Bus
CPU
Motorola 68020)
with Intel 386 or
(not compatible
INT/INT
AR
PCM
System
Interface
Line
Interface
T1/S2 Line
Local CPU BusLocal CPU Bus
CPU Bus ArbitrationCPU Bus Arbitration
FALC54
PEB 2254
MUNICH32
20320PEB
PEB 20320
Introduction
User’s Manual 31 01.2000
Figure 11
MUNICH32 in a System using Multiport Memory
Note: To r educe comp lexity th e host int erfac e is not expli c itly shown here.
ITS07373
System Bus
Controller
Multi Port RAM CPU
INT/INT
AR
Local CPU BusLocal CPU Bus
CPU Bus ArbitrationCPU Bus Arbitration
System Bus
Memory
Multi Port
20320
MUNICH32
PEB
2254
FALC54
PEB Controller
Interrupt Memory
System
Controller
Interface
Line
T1/S2 Line
Interface
System
PCM
PEB 20320
Functional Description
User’s Manual 32 01.2000
2 Functional Description
2.1 Serial Interface
The seri al interface of MU NICH32 inc lud es a dat a re ce iv e (R DA TA) an d a data transm it
line (TDATA) as well as the accompanying control signals (RCLK = Receive Clock,
RSP = Receive Synchronization Pulse, TCLK = Transmit Clock, TSP = Transmit
Synchronization Pulse). The timings of the receive and transmit PCM highway are
indepen dent of each o ther, i.e. the frame positi ons an d c loc k phases ar e no t c orrel ate d.
Data is tran smitted and received either at a rate of 2.048 Mbit /s for the CEPT 32-Channel
European PCM format (Figure 14) or 1.544 Mbit/s or 1.536 Mbit/s for the
T1/DS1 24-Channel American PC M format (Figure 12 and Figure 13). MUNICH32 may
also be connected to a 4.096-Mbit/s PCM system (Figure 15), where it handles either
the even - or odd-num bered time slots, so all 64 time slots can b e covered by connec ting
two MUNICH32s to the PCM highway.
The actual bit rate of a time slot can be varied from 64 Kbit/s down to 8 Kbit/s for the
receive and transmit direction. A fill mask code specified in the time slot assignment
determines the bit rate and which bits of a time slot should be ignored. Any of these
time slots can be combined to a data channel allowing transmission rates from 8 Kbit/s
up to 2.048 Mbit/s.
The frame alignment is established by the transmit and receive synchronization pulse
(TSP, RSP), respectively. The sampled rising edge of TSP identifies the current bit on
the serial line (TDATA) as the last bit of a PCM frame. The sampled rising edge of RSP
indicates that the current bit on the serial line (RDATA) is the first bit of a PCM frame.
The F-bit for the 1.544 MHz T1/DS1 24-channel PCM format is ignored in receive
direction, the corresponding bit is tristate in transmit direction. It is therefore assumed
that this channel is handled by a different device.
For test purp oses four diffe rent test l oops c an be swit che d. In a com plete loop all log ical
channe ls a re m irro red e ith er fro m seri al d ata o utp ut to inp ut (i nte r nal loo p) o r vic e vers a
(external loop).
In a channelwise loop one single logical channel is logically mirrored either from serial
data output to input (internal loop) or vice versa (external loop).
A detailed description of the different loops is found in Chapter 4.2.1 and Chapter 5.1.
PEB 20320
Functional Description
User’s Manual 33 01.2000
Figure 12
T1/DS1 Mode PCM Frame Timing 1.544 MHz
Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC,
TMB, TMR, V.110/X.30) or received as ‘1’-bit (TMA; one overwrite).
Note 2: The fill/mask bit for the F-bit is not defined. TDATA is tristate for the F-bit, and
the F-bit is ignored in the receive direction.
Note 3: TSP and RSP must have one single rising and falling edge during a
125 µs PCM frame.
ITD03496
T1/DS1 - Mode Receive Frame Timing
1 1 0 1 0 1 1 0
Fill/Mask : Slot 0
Fill/Mask : Slot 0
1 0 0 1 1 0 0 0
T1/DS1 - Mode Transmit Frame Timing
TCLK
TSP
TDATA
FILL/MASK
0SLOT 23SLOT 1SLOT 0 125 µs
PCM - Frame
SLOT 0 SLOT 1SLOT 23
123456701234567
F
7F01234567
7
6
5
4
3
21
0
F
7
SLOT 23 SLOT 1SLOT 0
FILL/MASK
RDATA
RSP
RCLK
DATA DATA DATA DATA DATA DATA
6
6
PEB 20320
Functional Description
User’s Manual 34 01.2000
Figure 13
T1/D S1 Mo de PCM Frame Tim ing 1.536 MHz
Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC,
TMB, TMR, V.110/X.30) or received as ‘1’-bit (TMA; one overwrite).
Note 2: TSP and RSP must have one single rising and falling edge during a
125 µs PCM frame.
ITD03497
T1/DS1 - Mode Receive Frame Timing
1 1 0 1 0 1 1 0
Fill/Mask : Slot 0
Fill/Mask : Slot 0
1 0 0 1 1 0 0 0
T1/DS1 - Mode Transmit Frame Timing
TCLK
TSP
TDATA
FILL/MASK
0SLOT 23SLOT 1SLOT 0 125 µs
PCM - Frame
SLOT 0 SLOT 1SLOT 23
123456701234567
701234567
SLOT 23
FILL/MASK
RDATA
RSP
RCLK
DATA DATA DATA DATA DATA DATA
6
67
6
5
4
3
21
0
7
SLOT 1SLOT 0
PEB 20320
Functional Description
User’s Manual 35 01.2000
Figure 14
CEPT Mode PCM Fra me Timing
Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC,
TMB, TMR, V.110/X.30) or received as ‘1’-bit (TMA; one overwrite).
Note 2: TSP and RSP must have one single rising and falling edge during a
125 µs PCM frame.
ITD03498
CEPT - Mode PCM - Frame Timing
1 1 0 1 0 1 1 0
Fill/Mask : Slot 0
Fill/Mask : Slot 0
1 0 0 1 1 0 0 0
CEPT - Mode Transmit Frame Timing
TCLK
TSP
TDATA
FILL/MASK
0SLOT 31SLOT 1SLOT 0 125 µs
PCM - Frame
SLOT 0 SLOT 1SLOT 31
123456701234567
701234567
SLOT 31
FILL/MASK
RDATA
RSP
RCLK
DATA
6
67
6
5
4
3
21
0
7
SLOT 1SLOT 0
DATADATADATADATA DATA DATA
PEB 20320
Functional Description
User’s Manual 36 01.2000
Figure 15
4.096 Mbit/s PCM Frame Timing
Note 1: A bo x in a bi t of the R DATA l ine mean s that this bit is igno red (HDL C,
TMB, TMR, V.110/X.30) or received as ‘1’-bit (TMA; one overwrite).
Note 2: TSP and RSP must have one single rising and falling edge during a
125 µs PCM frame.
ITD03528
01234567
SLOT 0 SLOT 1
7
6
5
4
3
21
0
SLOT 31
7
6
5
4
3
21
0
125 µs
TSP
RSP
4.096 Mbit/s PCM-format: even numbered slot allocation
4.096 Mbit/s PCM-format: odd numbered slot allocation
RSP
TSP
01234567
SLOT 31
01234567
SLOT 0
7
6
PEB 20320
Functional Description
User’s Manual 37 01.2000
Figure 16
Example: Programmable Channel Allocation for 32 Time Slots
Figure 17
Example: Programmable Channel Allocation for 24 Time Slots
ITD03499
125 µs
0
0
32 x 64 kbit/s
1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031
121 3 4 1 5 6 78791
ITD03500
125 µs
01 2 345678 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
012 34512 63
24 x 64 kbit/s
PEB 20320
Functional Description
User’s Manual 38 01.2000
2.2 Microprocessor Interface
A 64-channel DMA controller (32 channels in receive direction and 32 channels in
transmit direction) with buffer chaining capability is integrated in the MUNICH32. It
provides DMA functions for up to 32 full duplex channels and allows data transfer
between the serial interface and an external memory. The MUNICH32 performs long
word by long word transfers on a 32-bit bidirectional data bus (D(31:0)) and addresses
up to 4 G Byt e of RAM with a 3 0-b i t add r es s bus ( A(3 1 : 2)) . T h e ch ip a l way s w ork s as a
system bus master and can be operated in either a Intel or Motorola environment.
MUNICH32 receives commands and data from the host processor via the shared
memory. The host stores the action specification containing configuration initialization
and monitor commands in the memory. Afterwards the host informs the MUNICH32 by
generating an action request pulse (AR line). The MUNICH32 reacts by reading the
action specification and informs the microprocessor by appending the respective
interrupt information to the interrupt queue. In addition, the INT/INT line is activated
during t he write access belonging to the interrupt specification.
The timi ng of the mi cropro cessor in terface is es tablis hed ac cordin g to the Intel 80 386 or
Motorola 68020 processor. The system clock (SCLK) provides the fundamental timing
for the µP in terface and is the internal d evice clock. Each bus cycle performs a long word
(B16 = 1) or a word (B16 = 0) transfer and takes four system clock periods in the fastest
case, any number of wait clock cycles can be inserted.
MUNICH32’s architecture is based on a 32-bit data structure. Therefore MUNICH32
performs long word operations preferably. While the word operation mode is selected the
long word operation is divided into two consecutive word operations. In the case of a
read acc ess the data of th e two word s are connec ted toget her to buil d a 32-bit long word
before processing.
For a read access first the MSB bytes of a long word will be transferred and then the
LSB bytes via D(15:0).
For a write access first the LSB-bytes of a long word will be transferred and then the
MSB bytes via D(15:0).
The signal B16 cannot be changed dynamically and should be set to ‘1’ in Intel parity
mode (parity mode is not available in 16-bit word Intel mode).
Mode Operation Mode B16 BE(3–0) Access
Intel
Motorola
1
0
0
1
0
0
0H
3H
CH
0H
8H
AH
long word
MSB word
LSB word
long word
MSB word
LSB word
PEB 20320
Functional Description
User’s Manual 39 01.2000
2.2.1 Intel M ode
The Intel mo de has two sub modes – parity mode (even pari ty) and no n parity mode – to
be chosen by strapping PM to ‘1’ or ‘0’ respec tiv el y.
In Int e l mod e t h e lo we r (hi gh e r) or de r e d by te o f a lo ng wor d (D 31 … D0) is assigned to
the lower (higher) ordered physical address.
The read or w rite bus cycle is controlle d by the signals W/R, ADS and READY as shown
in Figure 18, Figure 19. Each bus cycle consis ts of two bus states (S1 , S2). During state
S1 the a dd ress signa ls an d bus cycle defin ition si gnals a re driven vali d. Sim ultane ously ,
the address status ADS is asserted to indicate their availability. The bus cycles are
terminated by asserting READY. READY is ignored on the first bus state S1 and
sampled at the end of the following state S2. If READY is no t as ser ted i n S 2 th en wai t
cycles SW are inserted until a bus cycle end is detected. During a read cycle the
MUNICH32 floats its data signals to allow external memory to drive the data bus.
The inpu t data and parity bits DP3–0 (i f parity m ode is sele cted) is latc hed when R EADY
is ass erted. During a write cyc le MUNICH 32 drives the data sign als and pa rity bits DP 3–
0 (if parity mode is selected) beginning in the second clock period of S1 until the first
clock period following the cycle acknowledgment READY. If a bus cycle error indicated
by BERR has o ccurred, the MUNI CH32 termin ates the bus cyc le. In c ase of a re ad cycl e
in the control and configuration section an action request fail interrupt is generated and
the action is suspended. In case of a read cycle in the transmit data section the
corresponding frame is aborted and a FO interrupt is generated. In all other cases of read
or write cycles terminated with an erro r condition no actions are perf ormed.
A 4-bit data byte parity bus DP3–0 is used in Intel mode if parity mode is selected by
strapping PM to ‘1’. During a read access DP3–0 is supposed to contain the parity of
D(31:24 ), D(23:16), D(15:8 ) and D(7:0) resp ectively. A low a ctive output PCHK ind icates
whether the parity was correct (PCHK = 1) or wrong (PCHK = 0) in the clock cycle after
the data/parity is latched. P CHK sta ys lo w 1 or 2 c loc k cy cl es . N o f urthe r ac tio n i s taken
as consequence to a parity fail.
As the memory access is performed by using one common system bus, bus
manage ment is do ne with th e signals HOLD, HLDA and HLDAO as shown i n Figure 20.
The wired or HOLD li ne is driven high whene ve r one of the MUN IC H3 2s ha s to perform
a bus trans fer. The ac tiv at ed H O LD AC KNOW LED GE ind ica tes tha t t he bu s c ont rol wil l
be released. If the specific device has activated the HOLD itself, it will start the memory
access. Otherwise it will pass the signal to the next cascaded device. Several memory
accesses may be required if the MUNICH32 has not been granted access recently.
In this example of four MUNICH32 devices sharing the same bus,
each device will generate four memory cycles, giving a total of 16 cycles per
HOLD/HLDA/HLDAO tenure. In order to prevent blocking in the case of continuous
request by one device, the MUNICH32 does not generate another HOLD REQUEST
before the HOLD ACKNOWLEDGE has been deactivated.
PEB 20320
Functional Description
User’s Manual 40 01.2000
If the HOLD ACKNOWLEDGE is driven low while the MUNICH32 is performing a bus
cycle, the bus is released later than two clock periods after de-assertion of HOLD
ACKNOWLEDGE. The current bus cycle is finished with a bus cycle error. This action
should be followed by an ASP.RES as described in Chapter 4.2.1.
Figure 18
Read Cycle Timing Diagram (Intel mode)
ITD03501
S1 S2 S1 S2 S1 S2S
WW
S
READ READ BERR
SCLK
BE(3:0)
W/R
ADS
READY
[DP3-DP0], D(31:0)
BERR
Tristate
A31-A2
[A27-A2]
[PCHK]
PEB 20320
Functional Description
User’s Manual 41 01.2000
Figure 19
Write Cycle Timing Diagram (Intel mode)
ITD03502
WRITE WRITE BERR
SCLK
BE(3:0)
W/R
ADS
READY
[DP3-DP0], D(31:0)
BERR
Tristate
A31-A2
[A27-A2]
INT
[PCHK]
PEB 20320
Functional Description
User’s Manual 42 01.2000
Figure 20
Bus Management for Intel Bus Mode
Note 1: Bus Cycle means, that the MUNICH32 under consideration starts a read or
write access at m ost 4 clock periods a fter HLDA is as serted afte r its HOLD. Th e
MUNICH32 terminates the cycle typically two clock periods after the last
bus cycle.
Note 2: In the Bus Management example it is assumed that the MUNICH32 under
consider ation has a highe r priority than the o ther bu s maste r. HOLD (inte rnal) i s
therefore the internal request generated by the MUNICH32, HOLD (external)
the signal on the external HOLD line, being the OR combination of the HOLD
signal generated by the MUNICH32 and the other bus master(s).
Note 3: A typical configuration example for a system with several bus masters is given
in Figure 4 and Figure 5.
ITD03503
SCLK
HOLD (extern)
HOLD (intern)
HLDA
HLDAO
Bus Cycle
Max. 4 Clock Periods
~
~~
~
MUNICH32
gets the Bus gets the Bus
Another Bus Master requests
No Bus
TristateTristate
Tristate Tristate
PEB 20320
Functional Description
User’s Manual 43 01.2000
2.2.2 Motorola Mode
In Motorola mode the bus is used in an asynchronous manner. The bus operation uses
the handshake lines (AS, DS, DSACK and BERR) to co ntro l data tr ansfer as show n in
Figure 21, Figure 22. Address strobe AS indicates the validity of an address on the
address bus (A31 …A2) and of the bus definition R/W (Read or Write cycle). It is
asserte d h alf a clock cy cl e a fter the begi nning of a bus c yc le . Th e data strob e D S si gnal
is use d as a cond ition for val id data of a w rite cycl e. MUNICH32 asserts DS on e full cloc k
cycle after the assertion of AS during a write cycle. T he data is placed on the bidirectional
data bus (D31 …D0) half a clock cycle after AS is driven low. For a read cycle,
MUNICH32 asserts DS to signal the external memory to drive the data on the bus. DS
is asserted at the same time as AS during a read cy c le. The data is lat che d w i th the las t
falling edge of the clock for that cycle.
The bus cycle is terminated if the data transfer acknowledge (DSACK) is asserted with
the falling edge of the third clock period. Otherwise MUNICH32 inserts wait cycles until
DSACK is recognized. AS and DS are dr iven hi gh hal f a cloc k period befo re bus cycle
end.
The bus error BERR is also a bus cycle termination indicator. It can be used in the
absenc e as well as in c onjun ction with DSACK. If an abnormal termi nat ion ha s occ urred
during a read cycle, MUNICH32 generates an interrupt and aborts the corresponding
transmit channel. For a write cycle no further action is performed.
As the MUNICH32 is used in a multi-bus-master application, bus arbitration has to be
done to avoid simultaneous system bus access by more than one master. In Motorola
mode the bus arbitration protocol of the 68020 is established using the signals BR, BG,
BGACK and BGO as shown in Figure 23. The wired-or Bus Request (BR) is driven low
to indic ate to the pro ce ss or th at one of the MU NIC H32 s requ ire s c on trol of the bus. Th e
activated Bus Grant (BG) signals the availab ility of the system bus. If the MUNICH32 ha s
activated the bus request itself, it asserts the wired-or Bus Grant Acknowledge to
indicate that it has assumed bus mastership. Otherwise it will pass the BUS GRANT
signal to the device cascaded next (BGO). At the same time it releases the Bus Request.
After finis hing the las t bus cycle, th e Bus Grant Ack nowledge i s deactivate d and the Bus
Grant is passed on. In order to preven t blocking in the case of cont inuous reques t by one
device, MUNICH32 does not generate another Bus Request before the external Bus
Request and Bus Grant Acknowledge have been deactivated.
After getti ng the bus m as ters hi p MU NI CH32 drives the b us and starts t he firs t b us cy cl e
one cl ock afte r assertio n of BG ACK. After finishing the memory access it releases the
bus and de-asserts BGACK at the same time.
PEB 20320
Functional Description
User’s Manual 44 01.2000
Figure 21
Read Bus Cycle Timing Diagram for Motorola Bus Mode
Figure 22
Write Bus Cycle Timing Diagram for Motorola Bus Mode
ITD03504
READ READ BERR
SCLK
A31-A2, BE (3:0)
R/W
AS
DSACK
D (31:0)
BERR
Tristate
DS
ITD03505
WRITE WRITE BERR
SCLK
A31-A2, BE (3:0)
R/W
AS
DSACK
D (31:0)
BERR
Tristate
DS
INT
PEB 20320
Functional Description
User’s Manual 45 01.2000
Figure 23
Bus Management for Motorola Mode
Note: 1. In the Bus Management example it is assumed that the MUNICH32 under
consideration has a higher priority than the other bus master. BR and BGACK
are wired AND lines to be pulled to ‘1’ by an external signal.
2. A typi cal co nfiguration ex am pl e for a system with sever al b us ma ste rs is given
in Figure 6.
ITD03506
SCLK
BR (extern)
BR (intern)
BGACK (extern)
BGACK (intern)
BGO
BG
Max. 4 Clock Periods
~
~~
~
MUNICH32
gets the Bus gets the Bus
Another Bus Master No Bus
requests
PEB 20320
Functional Description
User’s Manual 46 01.2000
2.2.3 DMA Priorities
Prioritization of Queueing DMA Cycles
The MUNICH32 will perform all pending accesses on the same bus tenure.
Note: Several bus transactions may be required if the MUNICH32 has not been given
access to the system bus for a long period of time. This is often seen in multi-
master systems where several MUNICH32 devices share the system bus.
Priority Interrupt
Highest priority Receive link list including accesses to the descriptors
Transmit link list including accesses to the descriptors
Lowest priority Configuration of a channel (action requests)
PEB 20320
Functional Description
User’s Manual 47 01.2000
2.3 Basic Functional Principles
MUNICH32 is a Multichannel Network Interface Controller for HDLC, offering a variety
of additional features like subchanneling, data channels comprising of one or more
time slots, DMI 0, 1, 2 transparent or V.110/X.30 transmission and programmable rate
adaption. MUNICH32 performs formatting and deformatting operations in any network
configuration, where it implements, together with a microprocessor and a shared
memory, the bit oriented part (flag, bit stuffing, CRC check) of the layer 2 (data link
protocol level) functions of the OSI reference model.
The blo ck diag ram is sho wn in Figure 3. MUNICH32 is des igned to handle up to 32 da ta
channel s of a 1.536/ 1.544 M bit/s T1/DS1 24-ch annel, 2.048-M bit/s C EPT 32-ch annel or
a 4.096-Mbit/s 32-channel PCM highway. The device provides transmission for all bit
rates from 8 Kbit/s up to 2.048 Mbit/s of packed data in HDLC format or of data in a
transparent format supporting the DMI mode (0, 1, 2) or V.110/X.30 mode. Tristating of
the transmission line as well as switching a channelwise or complete loop are also
possible. An on-chip 64-channel DMA generator controls the exchange of data and
channel control information between the MUNICH32 and the external memory.
The MUNICH32 processes receive and transmit data independently for each time slot
and transm is si on di rec t io n resp ec tiv ely (blo ck s TF = Transmit Forma tter, RD = Receive
Deformatter). The frame counters are reset by the rising edges of the RSP or TSP line.
The processing units TF and RD work with a multiplex managemen t, i.e. there exis ts only
one protocol handler, which is used by all channels in a time sharing manner (see
Figure 24 and Figure 25). The actual configuration, e.g. transmission mode, channel
assignment, fill/mask code or state of the protocol handlers is retrieved from the
Config uration and State RA M (CSR) at the beginning of the time slot and reload ed to the
CSR at t he end. T he cont rol unit (CD) con trols th e acce ss to th e CSR and allow s writin g
of reconfiguration information only if the continuous transfer of the configuration
information between the CSR and the formatters (TF and RD) will not be disturbed. In
receive direction, 32 unpacked data bits are first accumulated and then stored into an
on-chip receive buffer (RB) for transfer to the shared memory. As soon as the RB
receive s 32 b its for a chan nel it reques ts ac cess to the paralle l mic roproc essor bus. Th e
on-chip transmit buffer (TB) is always kept full of data ready for transmission. The TB will
request more data when 32 bits become available in the ITBS. These buffers allows a
flexible access to the shared memory in order to prevent data underflow (Tx) and data
overflow (Rc).
The transm it buffer (TB) ha s a size of 64 long word s (= 256 byte s). In this buffer, dat a of
8 PCM frames can be stored for each data channel. In this case, there are max. 1 ms
between access to the shared memory and data supply to the Transmit Formatter. In
order to meet these requiremen ts a variable and program mable part of the buffer (ITBS)
must be allocated to each data channel (see Figure 26).
PEB 20320
Functional Description
User’s Manual 48 01.2000
Figure 24
Multiplex Management Receive Direction
RDATA Bit 0 1Bit 2Bit
SCLK
Active
RCLK
(external)
Channel
Receive
1
X
Channel
Active
Receive
0
X
(internal)
2
X
for into RD
Load CD, CSR Data
X
1
Phase of RD, CM
Protocol Operation
Bit 7Bit
~
~
~
~
01Bit
for into RD
Load CSR Data
~
~~
~
~
~
~
~
1
X
no Operation of RD,
Wait Phase Reload RD
into CSR
X
3
2
X
2
X
Operation disabled
RD Protocol
Data into CSR
Channel Config
might write new
RDATA
CSR
CD RD
CSR
1
X
...
CM
RD
CSR
X
Operation disabled
RD Protocol
CM might write new
Channel Config
Data into CSR
CSR
Protocol
Operation disabled
FIFO CM
CSR
X
1
RD
RDATA
CD
2
RD
ITD04397
PEB 20320
Functional Description
User’s Manual 49 01.2000
Figure 25
Multiplex Management Transmit Direction
ITD04398
TDATA
TCLK
Active Transmit
Channel (external)
SCLK
Active Transmit
Channel (internal) X X
Load CSR Data
TF Protocol
Operation disabled
Protocol Operation
Phase of TF, CM
might write new
Channel Config
Data into CSR Data into CSR
Channel Config
CM might write new
no Operation of TF
Wait Phase
Operation disabled
TF Protocol
into CSR, CD
Reload TF
X
X X
Bit 7 0Bit Bit 1 Bit 6 Bit 7 0Bit
CSR
CSR TF
CM X
...
CSR
CM
FIFO
CSR
CD
TF
TDATA
~
~~
~
~
~
~
~~
~
~
~
~
~~
~
0
120
1
1
X
2
X
0
X
1
X
1
for into TF
X
1
TF
PEB 20320
Functional Description
User’s Manual 50 01.2000
For example:
a)2.048-Mbit/s PCM highway
32 × 64-Kbit/s data channels (8 bits are sent with each PCM frame). Two long words
of the buffer are allocated to each data channel.
b) 1 × 2.048-Kbit/s data channel
The maximum buffer size for one channel (63 long words) is allocated to this data
channel.
c) 6 × 256-Kbit/s and 8 × 64 Kbit/s data channels.
Eight long words of the buffer are allocated to each of the 6 data channels with
256 Kbit/s and two long words are assigned to each of the 8 data channels with a
transmis si on rate of 64 Kbit/s.
The cho ice of the individ ual buffe r size of each data channel can be m ade in t he channe l
specification (shared memory). The buffer size of one channel is changeable without
disturbing the transmission of the other channels.
Figure 26
Partitioning of TB
ITD04396
CD
TF
Unused
TB
Active Transmit
Channel (internal) Used as Address Offset for TB
ITBS of Channel X
1
64 Long Words
0
X
X
3
2
X
ITBS of Channel
ITBS of Channel
ITBS of Channel
PEB 20320
Functional Description
User’s Manual 51 01.2000
The receive buffer (RB) is a FIFO buffer and also has a size of 64 long words, which
allows storing the data of eight complete PCM frames before transferring to the shared
memory.
Figure 27
Partitioning of RB
The data transfer to the shared memory is performed via a 32-bit microprocessor
interface working either in SIEMENS/Intel or Motorola bus mode. Figure 28 shows the
division of the shared memory required for each MUNICH32:
–Configuration start address located at a programmable address
–Control and configuration section
–An interrupt circular queue with va riab le si ze
–Descriptor and data sections for each channel.
ITD04447
64 Long Words
Active Receive
Channel (internal)
Stored in RB
together with Data/Status
Word from RD
CD
RD
RB
PEB 20320
Functional Description
User’s Manual 52 01.2000
Figure 28
Memory Division for up to four MUNICH32
Interrupt
Queue
Receive
Descriptor
DATA
Receive Receive
DATA
Descriptor
Receive Descriptor
Receive
Channel 31 spec.
Channel 0 spec.
Time-Slot Assignment
INTERRUPT QUEUE Spec.
ACTION SPEC.
Transmit
Descriptor
DATA
TransmitTransmit
DATA
Descriptor
Transmit
Transmit
Descriptor
Control Start
Address
CI(4:0)
Control and
Configuration
section
section
Configuration
Control and
CI(4:0)
Descriptor
Transmit
Transmit
Descriptor
DATA
Transmit Transmit
DATA
Descriptor
Transmit
ACTION SPEC.
INTERRUPT QUEUE Spec.
Time-Slot Assignment
Channel 0 spec.
Channel 31 spec.
Receive
Descriptor
Receive
Descriptor
DATA
Receive
Receive
DATA
Descriptor
Receive
Queue
Interrupt
Interrupt
Queue
Receive
Descriptor
DATA
Receive Receive
DATA
Descriptor
Receive Descriptor
Receive
Channel 31 spec.
Channel 0 spec.
Time-Slot Assignment
INTERRUPT QUEUE Spec.
ACTION SPEC.
Transmit
Descriptor
DATA
TransmitTransmit
DATA
Descriptor
Transmit
Transmit
Descriptor
CI(4:0)
Control and
Configuration
section
section
Configuration
Control and
CI(4:0)
Descriptor
Transmit
Transmit
Descriptor
DATA
Transmit Transmit
DATA
Descriptor
Transmit
ACTION SPEC.
INTERRUPT QUEUE Spec.
Time-Slot Assignment
Channel 0 spec.
Channel 31 spec.
Receive
Descriptor
Receive
Descriptor
DATA
Receive
Receive
DATA
Descriptor
Receive
Queue
Interrupt
ITD03507
Control Start
Address
Control Start
Address
Control Start
Address
Current Receive Descriptor Address
0
...
31
Current Transmit Descriptor Address
31
...
0
0
...
31
Current Transmit Descriptor Address
31
...
0
Current Receive Descriptor Address
Current Receive Descriptor Address
0
...
31
Current Transmit Descriptor Address
31
...
0
Current Receive Descriptor Address
0
...
31
Current Transmit Descriptor Address
31
...
0
PEB 20320
Functional Description
User’s Manual 53 01.2000
The shared memory allocated for each transmit and receive channel is organized as a
chaining list of buffers set up by the host. Each chaining list is composed of descriptors
and data sections. The descriptor contains the pointer to the next descriptor, the start
address and the s ize of a d ata secti on. It als o include s control informati on like f rame end
indication, transmission hold and rate adaption with interframe time-fill.
In the transmit direction the MUNICH32 reads a transmit descriptor, calculates the data
address , writes t he current t ransmit des criptor addre ss into the CCS, and fil ls the on- chip
transmit buffer. When the data transfer of the specified section is completed, the
MUNICH32 releases the buffer, and branches to the next transmit descriptor. If a frame
end is indicated the HDLC, TMB or TMR frame will be terminated and a specified number
of the inte rfram e ti me -fil l by te w il l be se nt in orde r to pe rform rate ada pti on. If frame end
is found in a transmit descriptor TMA channel the specified number of programmable
TMA flags is appended to the data in the descriptor. If frame end is found in a transmit
descriptor of a V.110/X.30 channel the frame is aborted (after the data in the descriptor
are sent) by finishing the current 10-octet frame with ‘zeros’ a nd sending 2 more 10-octet
frames with ‘zeros’ which le ads to a loss of sy nchronism on the peer si de. An adjust ment
for the inserted zeros in HDLC is programmable, which leads to a reduction of the
specif ied nu mber of inte rfram e tim e-fi ll by 1/8th of the num be r o f z ero in sertions. Th is can
be used to se nd long HDLC frames with a more or less fix ed data rate in spite of the zero
insertions. A maskable interrupt is generated before transmission is started again.
PEB 20320
Functional Description
User’s Manual 54 01.2000
The following Sections give Examples of Typical Transmit Situations for the
Individual Modes
Variable Size Frame Oriented Protocols (HDLC, TMB, TMR)
Normal operation, handling of frame end (FE) indication and hold (H) indication.
Note: 1. FNUM0 must be set to zero.
2. Flag = 7EH for HDLC
00H for TMB, TMR
IC = 7EH for HDLC and IFTF = 0
FFH for HDLC and IFTF = 1
00H for TMB, TMR
3. After sending the FNUM2 –1 IC characters the device starts polling the hold bit
in the transmit descriptor once for each further sent IC character. It also rereads
the pointer to the next transmit descriptor once with each poll of the hold
indication. The pointer to the next transmit descriptor can be changed while
HOLD = 1 is set. The value of the pointe r, (read in the po ll wher e HOLD = 0) is
used as the next descriptor address. If more than 6 IC characters will be sent,
the use of the Transmit Hold (TH) should be considered as an alternative to
using the descriptor hold bit. See Chapter 5.3.2.
PEB 20320
Functional Description
User’s Manual 55 01.2000
Figure 29
ITD04446
FE=0
H=0 0=H 1=FE FE=1
H=1
Flag Data 4
....
...
Data 1 Data 2 Data 3
Transmit
Descriptors
Data
Sections
...
FNUM1+1
3Data
Poll
H=1? Poll
H=0
Next
Transmit
Descr. Descr.
Transmit
Next
Descr.
Transmit
Next
FNUM0 FNUM1 FNUM2
Data 4
(Data 1, Data 2) Flag,
FNUM2
...
Flag
ΙC, , CΙ
...
Frame (
Frame )Frame ()
...
ΙC,CΙ
Flag, CΙ,Flag
ΙC, ,CΙCΙ
...
,
PEB 20320
Functional Description
User’s Manual 56 01.2000
Fixed Size Frame Oriented Protocols (V110/X.30)
Normal operation, E, S, X change (indicated by the V.110-bit in the transmit descriptor)
Example for TRV = ‘11’
Note: 1. FNUM must be 0 for all transmit descriptors.
2. The actual E-, S-, X-bits have to be in the first transmit descriptor after reset.
3. As shown in the example the contiguous parts of a data section belonging to
one descriptor are sent in contiguous frames (DATA 1(1) are the bytes 0 –3 of
DATA 1, DATA 1(2) are the bytes 4 –7 of DATA 1). If the end of a data section
is reached within a frame, the frame is continued with data from the next data
section belonging to a transmit descriptor with the bit V.110 = 0
(DATA 2(2) = byte 4 of DATA 2 , DATA 3(1) =byte 0–2 of DATA 3).
4. The E-, S-, X-bits are only changed from one frame to the next not within a
frame. The ch ang e oc cu rs in the first fra me whic h do es not c on tain data of the
previous data section.
5. Neither FE nor H m ay be s et to 1 during a no rmal operatio n o f th e mode. The y
both lead to an abort of the serial interface.
PEB 20320
Functional Description
User’s Manual 57 01.2000
Figure 30
ITD04444
Next
Transmit
Descr.
NO=2
V110=1
FE=0
H =0 0=
0=H 0=FE
V110
NO=8 5=NO
V110
FE=0
H=0
=0 1=
0=H 0=FE
V110
NO=2
0=
0=H 0=FE
V110
NO=9
Frame ( E, S, X, Data 1 )
(1) (2) (1) (2) (1) (2)
.....
...
10 Octets 10 Octets 10 Octets 10 Octets 10 Octets
E, S, X, Data 1 E´, S´, X´,
Transmit
Descriptors
Data
Sections
...00
Descr.
Transmit
Next
Descr.
Transmit
Next
Descr.
Transmit
Next
Descr.
Transmit
Next
Frame ( E, S, X, Data 1 ) Frame ( E, S, X, Data 2 ) Frame ( E, S, X, Data 2, Data 3 ) Frame ( E´, S´, X´, Data 3 )
Data 2 Data 3
PEB 20320
Functional Description
User’s Manual 58 01.2000
Fixed Size Frame Oriented Protocols (V.110/X.30)
Handling of frame end (FE) indication
Note: 1. FNUM mu st be ‘0’ for all transmit descriptors.
2. The f rame (E, S, X, DATA 2(2)) is the beginnin g of a 10-oct et frame. I t stops with
the octet no. y, containing the last data bit of DATA 2 to be sent.
3. Sin c e y = 1, …, 10 the 20 + y times 00H characters sent afterwards cause the
peer sta tion to recogn ize 3 cons ecuti ve 10-oct et fr ames with fram e error which
leads to a loss of synchronism in the peer station.
4. For y = 10 DATA 2 i s identic al to D ATA 2 (1) and 30 times 00 H characters are
sent after frame (E, S, X, DATA 1(2), DATA 2(1)).
5. The E-, S-, X-bits are supposed to be loaded by an earlier transmit descriptor
in the example. A descriptor changing them (with V.110-bit set) can be put
between, before or after the descriptors in the example. It will change these bits
according to the rules discussed previously.
PEB 20320
Functional Description
User’s Manual 59 01.2000
Figure 31
ITD04448
V110
FE=0
H=0
=0 0=
0=H 1=FE
V110 V110
FE=0
H=0
=0
Frame ((1) )Frame ((2) )00,......,00
2Data Data 3 )
(1)
(
Frame
....
...
10 Octets 10-y Octets 20+y Octets 10 Octets
Data 1 Data 2 Data 3
Transmit
Descriptors
Data
Sections
... E, S, X,
10 Octets
,X,S,
E, (1)
2DataData 1
Frame ((2) )
y=1,...,10
1Data
E, S, X, E, S, X,
PEB 20320
Functional Description
User’s Manual 60 01.2000
Fixed Size Frame Oriented Protocols (V110/X.30)
Handling of hold (H) indication
Figure 32
ITD04449
V110
FE=0
H=0
=0 0=
1=H 1=FE
V110 V110
FE=0
H=0
=0
Frame (
(1)
)Frame (
(2)
)00,......,00
2Data Data 3 )
(1)
(
Frame
....
...
10 Octets 10-y Octets 20+y Octets 10 Octets
Data 1 Data 2 Data 3
Transmit
Descriptors
Data
Sections
... E, S, X,
10 Octets
,
X,S,
E,
(1)
2DataData 1
Frame (
(2)
)
y=1,...,10
00 00 ... 00 00
Poll
H=1? Poll
H=0
E, S, X,1Data
E, S, X,
PEB 20320
Functional Description
User’s Manual 61 01.2000
Time Slot Oriented Protocol (TMA)
Normal operation, handling of frame end (FE) indication and hold (H) indication.
Note: 1. FNUM must be set to zero.
2. TC = FFH for TMA and FA = 0
the programmed flag with TMA and FA = 1
3. After sending the FNUM2 –1 IC characters the d evice starts poll ing the hold bit
in the tra nsmit descriptor once for each further sent IC character. It also rereads
the pointer to the next transmit descriptor once with each poll of the hold
indication. The pointer to the next transmit descriptor can be changed while
HOLD = 1 is set. The value of th e pointe r, (read in the po ll wher e HOLD = 0) is
used as the next descriptor address. If more than 6 IC characters will be sent,
the use of the Transmit Hold (TH) should be considered as an alternative to
using the descriptor hold bit. See Chapter 5.3.2.
PEB 20320
Functional Description
User’s Manual 62 01.2000
Figure 33
ITD04445
FE=0
H=0 0=H 1=FE FE=1
H=1
TC Data 4
....
...
Data 1 Data 2 Data 3
Transmit
Descriptors
Data
Sections
...
FNUM1+1
Data 3 TC, TC, TC,........TC, TC
Poll
H=1? Poll
H=0
Next
Transmit
Descr. Descr.
Transmit
Next
Descr.
Transmit
Next
FNUM0 FNUM1 FNUM2
Data 4
Data 1 Data 2
Time-Slot
Boundaries TC,..................,TC TC, TC,.............TC,
FNUM2
...
...............
PEB 20320
Functional Description
User’s Manual 63 01.2000
An activated transmission hold (hold bit in descriptor) prevents the MUNICH32 from
sendin g more data. If a fr ame en d has not occu rred just b efore, th e current f ram e will b e
aborted and an interrupt generated. Afterwards, the interframe time-fill bytes will be
issued until the transmission hold indication is cleared. There is a further transmit hold
(TH ) bit in the Ch annel Speci ficati on (CC S) in addit ion t o the ho ld bit in th e descri ptor .
Setting the transmit hold (TH) bit by issuing a channel command will prevent further
polling of the tra nsmi t descriptor (see Chapter 5.3.2).
This hold bit (CCS.TH) is interpreted in the CD; it causes the transmit formatter to stay
in the idle state and to send interframe time-fill after finishing the current frame. In the
case of a very short frame (< ITBS), this frame will stay in the TF and not be sent until
CCS.TH is removed. (In case of X.30/V.110 the current frame is aborted).
This means that the buffer TB is not emptied from the TF side after the current frame,
but still requests further data from the shared memory until it is filled. In the case of the
descriptor hold on the other hand, the TF empties the TB and there are no further data
requests from the shared me mory until the des criptor hold is wit hdrawn. Then TB is fille d
again a nd the TF is ac tiv at ed only afte r en ough data a r e p rov ide d i n the TB to prevent a
data underrun .
The Rea ction to the Transm it Hold Bit is now Discu ssed for the Diffe rent Modes in
the Following Sections
Variable Size Frame Oriented Protocols (HDLC, TMB, TMR)
Reaction to a channel specification containing TH = 1
Normal operation
Note: 1. IC = 7EH for HDLC and IFTF = 1
FFH for HDLC and IFTF = 0
00H for TMB or TMR
2. flag = 7EH for HDLC
00H for TMB or TMR
3. FNUM2 is ignored. The number of interframe time-fills sent between the first
frame and the second frame solely depends on the AR low pulse leading to the
action with the channel with TH = 0.
4. The times ∆t1 and ∆t2 are statistical but typi cally only a few clock cycles.
5. The TH bit (as all channel commands) is not synchronized with TB! (as
opposed to the H-bit in the descriptor) TH acts on the frame currently being
sent, not necessarily on the last frame currently stored in the TB. In the
example, TB may or may not have stored DATA 3 before the action request
with TH = 1 was issued. See Chapter 4.2.5 for a further discussion of this
issue.
6. If TH is ha nded over to CD outsi de of a frame, TH = 1 prev ents the MUNI CH32
from send ing the next frame.
PEB 20320
Functional Description
User’s Manual 64 01.2000
Figure 34
ITD04450
FE=0
H=
0
Flag Data 3
....
...
Data 1 Data 2
...
..., 1Data Flag, ΙC,
()
Frame Frame ()
CΙ,Flag
∆t1∆t2
TH=1 TH=0
in the Channel Specification
handed over from CM to CD handed over from CM to CD
in the Channel Specification
AR
....
....
,Data 2
Data 3
FNUM2
0=H 1=FE
PEB 20320
Functional Description
User’s Manual 65 01.2000
Fixed Size Frame Oriented Protocol (V.110/X.30)
Reaction to a channel specification containing TH = 1
Normal operation
Note: 1. The times ∆t1 and ∆t2 are statisti cal but typically only a few clock cycles.
2. The current frame processed, when TH = 1 is handed over to CD is aborted,
only 10 – y, (y = 1, …, 10) octets of it are sent. The device then starts to send
20 + y 00 H characters no mat ter how fast the TH bit is wit hdrawn. This ensures ,
that the peer site is informed about the abort with a loss of synchronism
3. The data section DATA 1 is split in the example; DATA 1(1) is sent in the
aborted fra me, all bits th at were read into the MUNICH32 with the sam e access
are discarded (they would have been sent in the next frame(s) if TH = 1 was
not issued) and the device starts the next frame with the bits DATA 1(3) of the
access to DATA 1 that follows the one getting the bits of DATA 1(1).
4. The TH (as all channel commands) is not synchronized with TB. TH acts on
the frame currently sent, not necessarily on the last stored data.
5. If TH is handed over to CD before a frame has started after an abort or after
reset no frame will start.
PEB 20320
Functional Description
User’s Manual 66 01.2000
Figure 35
Time Slot Oriented Protocol (TMA)
Reaction to a channel specification containing TH = 1
Note: 1. TC is the programmed TFLAG for FA = 1
FFH for FA = 0
2. The times ∆t1 and ∆t2 are sta tistical but typic ally only a few clock cycl es.
3. The TH bit (as all channel commands) is not synchronized with the TB! (as
opposed to the H-bit in the descriptor) TH ac ts to the data stream currently sent.
ITD04454
FE=
0
H=
0
....
...
Data 1
...
10-y Octets
1Data ...
∆t
1
TH=1 in the
Channel
AR
Frame ()
(1)
00
Specificaton
handed over
from CM to CD
00 0000 ..............
Channel
in the
TH=0
2
t∆
10 Octets
1DataFrame ()
(3)
20+y Octets
...
from CM to CD
handed over
Specificaton
E, S, X, E, S, X,
PEB 20320
Functional Description
User’s Manual 67 01.2000
Figure 36
ITD04452
FE=
0
H=
0
Data 3
....
...
Data 1 Data 2
...
FNUM0
1Data TC, ,TC TC,TC,
∆t1∆t2
TH=1 TH=0
in the Channel Specification
handed over from CM to CD handed over from CM to CD
in the Channel Specification
AR
,
....
Data 2 ,
Data 3
Time-Slot Boundaries
=
=FE
H
0
1
PEB 20320
Functional Description
User’s Manual 68 01.2000
Variable Size Frame Oriented Modes (HDLC, TMB, TMR)
Reaction to a channel specification containing TH = 1
Silencing of poll cycles for hold.
Note: An AR pulse for an action specification leading to TH = 1 should be issued after
(ITBS + 2) polls of the MUNICH32, where ITBS is the previously programmed
number of long words in the TB reserved for this channel.
PEB 20320
Functional Description
User’s Manual 69 01.2000
Figure 37
ITD04451
FE=
1
H=
1
Flag Data 2
....
...
Data 1 Data 2
...
FNUM0
Poll
H=1? Poll
H=0
FNUM0
..., 1Data Flag,
...
ΙC, , CΙ
...
()
Frame Frame ()
CΙ,Flag
ΙC, ,CΙCΙ...
,,
Poll
H=1?
Ι,C ...
No Poll
...
CΙ,
∆t
1
∆t
2
TH=1 TH=0
in the Channel Specification
handed over from CM to CD handed over from CM to CD
in the Channel Specification
AR
....
....
PEB 20320
Functional Description
User’s Manual 70 01.2000
Fixed Size Frame Oriented Protocol (V110/.30)
Silencing of poll cycles by TH = 1
Note: 1. The times ∆t1 and ∆t2 are statistical bu t typical ly only a few clock cycle s .
2. The TH bit (as all channel commands) is not synchronized with TB! (as
opposed to the H-bit in the descriptor) TH ac ts to the data stream currently sent.
3. In the example the proper use to silence a channel polling the HOLD bit of the
transmit descriptor is illustrated. The AR pulse is issued after the polling has
started and the H-bit is not reset before polling has stopped by the TH bit.
4. An AR pu lse for an action sp ecification leadin g to TH = 1 should b e issued after
(ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed
number of long words in the TB reserved for this channel.
PEB 20320
Functional Description
User’s Manual 71 01.2000
Figure 38
ITD04455
FE=
1
H=
1
....
...
Data 1 Data 2
...
10 Octets
1Data ...
PollH=1
∆t
1
TH=1
in the
Channel
AR
Frame ()
(1) (2)
)(
Frame Data 1
10-y Octets
00
Specif.
handed
over to CD
H=1 No Poll H=1 H=0
Poll
00 0000 ..............
from CM to CD
handed over
Specif.
Channel
in the
TH=0
2
t∆
10 Octets
2DataFrame ()
(1)
20+y Octets
E, S, X, E, S, X, E, S, X,
PEB 20320
Functional Description
User’s Manual 72 01.2000
Time Slot Oriented Protocol (TMA)
Reaction to a channel specification containing TH = 1
Note: 1. TC = FFH for TMA and FA = 0
the programmed flag for TMA and FA = 1
2. FNUM2 is ignored. The number of interframe time-fills between the first frame
and the sec ond frame solel y depends on the AR low pul se leading to the ac tion
with the channel with TH = 0.
3. The times ∆t1 and ∆t2 are sta tistical but typic ally only a few clock cycl es.
4. The TH bit (as all channel commands) is not synchronized with TB (as
opposed to the H-bit in the descriptor) TH acts on the data stream currently sent
not necessarily on the last data stored in TB. In the example TB may or may
not have stored DATA 3 before action request with TH = 1 was issued.
5. The d at a str e am is st o ppe d an d TC s e nt a f ter t he las t by t e o f DA TA 2 i s s ent .
The stopping is triggered by the FE = 1 bit in the descriptor.
6. If TH is bonded over to CD during interframe time-fill (TC) it prevents the
MUNICH32 from sending further data afterwards.
7. An AR pu lse for an action sp ecification leadin g to TH = 1 should b e issued after
(ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed
number of long words in the TB reserved for this channel.
PEB 20320
Functional Description
User’s Manual 73 01.2000
Figure 39
ITD04453
FE=
1
H=
1
Data 2
....
...
Data 1 Data 2
...
FNUM0
Poll
H=1? Poll
H=0
FNUM0
... 1Data
...
TC, , TC
... TC,TC, ,TC TC ...
,,
Poll
H=1?
,TC ...
No Poll
...
TC,
∆t1∆t2
TH=1 TH=0
in the Channel Specification
handed over from CM to CD handed over from CM to CD
in the Channel Specification
AR
,,TC ....
....
PEB 20320
Functional Description
User’s Manual 74 01.2000
In receive direction the MUNICH32 reads a receive descriptor, calculates the data
address, writes the current receive descriptor address into the CCS, and exchanges data
betwee n the on-c hi p rec eive bu ffer and the externa l me mo ry. After the data sectio n ha s
been fill ed, the MUNICH3 2 w rite s the num be r of sto r ed by te s (BNO ) into the de sc ript or.
If a fra me end has occurred the frame statu s is written i nto the des criptor and an interrupt
is generated. The frame status includes the CRC ch eck results and transmission error
information like ‘non octet of bits’, ‘aborted frame’, ‘data overflow’, ‘maximum frame
length exceeded’ and ‘frames with less than or equal to two data bytes’. An activated
reception-hold in the descriptor prevents the MUNICH32 from processing the receive
data. The incoming frames are discarded until the hold is deactivated.
Because the MUNICH32 is divided into two non-synchronized parts by the on-chip
buffers, two different kinds of aborting a channel transmission are implemented.
–Normal abort:This abort of a receive or transmit channel is processed in the
formatters of the serial in terface. The int erframe time-fill c ode is sent aft er aborting the
current issued frame. No accesses to the on-chip buffers are carried out, until the
abort is withdrawn. The handling of the link lists and the processing of the buffers by
the DMA controller are not affected by normal abort.
–Fast abort: A fast abort is performed by the DMA controller and does not disturb the
transmission on the serial interface. If this abort is detected the current descriptor is
suspended with an abort status immediately followed by a branching to the new
descriptor defined in the channel specification of the CCS.
For initia lization and contro l the host s ets up a Cont rol and Co nfiguratio n Section (CC S),
includ ing the action spec ification, interrup t queue specification, time slot assignment and
the cha nnel speci fication. The host initia tes an action, e.g. reconf iguration, ch ange of the
channel mode, reset or switching of a test loop by updating the CCS and issuing an
action request pulse. When the action request pulse is detected by the MUNICH32 it
reads the control star t address, then the action sp ecification and, if ne cessary, add itional
information from the CCS. After execution, the action request is acknowledged by an
interrupt.
MUNICH32 indicates an interrupt by activating the interrupt line and storing the interrupt
information including the corresponding channel number in the interrupt queue. The
interrupt queue is a circular buffer; MUNICH32 starts to write the interrupt queue
specification and fills it successively in a circular manner. The host has to allocate
sufficient buffer size and to empty the buffer fast enough in order to prevent overflow of
the queue.
PEB 20320
Functional Description
User’s Manual 75 01.2000
Monitoring functions are implemented in MUNICH32 to discover errors or condition
changes, i.e.
–Receive frame end
–Receive frame abort by overflow of the receive buffer or hold condition or recognized
ABORT flag
–Frame overflow, if a frame has to be discarded because of pending inaccessibility of
the chip memory
–Transmit fram e end
–Transmit frame abort (data underrun) by underrun of the transmit buffer or hold
condition or bus cycle error
–Change of the interframe time-fill.
–Loss of synchronism or change of framing bits (V.110, X.30).
–Short frame with no data content detected.
An error or condition change is indicated by an interrupt. The host may react to the
interrupt by either aborting or tristating the specific channel or with a channel
reconfiguration. To prevent underrun of the transmit buffer sufficient buffer size has to
be allocated to the channel.
A more detailed discussion of the receive procedure with examples is provided under the
detailed protocol description in Chapter 2.4.
PEB 20320
Functional Description
User’s Manual 76 01.2000
2.4 Detai led Protoco l Descriptio n
In the fo llowing s ect ion s the pro toc ol su ppo rt of the MU NIC H32 is desc ribe d in detail for
transmit and receive direction separately.
Each section starts with a discussion of the general features proceeds with protocol
variants and options from the channel specification and closes with a description of the
interrupts and special topics.
HDLC
Transmit Direction General Features
In transmit direction
–the starting and ending flag (7EH before and after a frame)
–the interframe time-fill between frames
–the zero insertions (a ‘0’-bit after 5 consecutive ‘1’s inserted within a frame)
–(optional) the Frame Check Sequence (FCS) at the end of a frame
is generated automatically.
Options
The different options for this mode are
–the kind of the interfram e tim e-fi ll ch arac ter in the cha nn el spe ci fic ati on
–7EH for IFTF = 0
–FFH for IFTF = 1
–the number of interframe time-fill characters as FNUM in the transmit descriptor. For
the values FNUM = 0, 1, 2 we have
–FNUM = 0 frame 1, 7EH, frame 2 (start flag = end flag)
–FNUM = 1 frame 1, 7EH, 7EH, frame 2
–FNUM = 2 frame 1, 7EH, IC, 7E H, frame 2
–the correction of the number of interframe time-fill characters by 1/8 of the number of
zero insertions by programming FA in the channel specification.
–FA = 0: FNUM from the transmit descriptor is taken directly to determine
the number of interframe time-fill characters as shown in Figure 39.
–FA = 1: FNUM from the transmit descriptor is reduced by 1/8 of the
number of the zero insertions of the frame corresponding to the
trans mit des cri pto r as sh ow n in Figure 40. This allows for a more or
less constant bit rate transmission for long HDLC frames.
PEB 20320
Functional Description
User’s Manual 77 01.2000
Figure 40
Note: 1. is the biggest integer smaller than .
1. For FNUM –< 0, y = 0
–the kind of Frame Check Sequence (FCS)
two kinds of frame check sequences are implemented by the CRC bit in the
chann el spe ci fic ati on
CRC = 0: the generator polynomial x16 +12 +x
5+1 is used
(2 byte F CS of C CITT Q.921)
CRC = 1: the generator polynomial x32 +x
26 +x
23 +x
22 +x
16 +x
12 + x11 +…
…x10 +x
8+x
7+x
5+x
4+x
2+x + 1
(4 byte FCS) is used
–the suppres sio n of the aut om atic gene rati on of the FCS is pro gram mable in
the channel specification:
–CS = 0: FCS generated automatically
CS = 1: FCS generation suppressed
and in the transm it des cri pto r
CSM = 0: FCS generated automatically if CS = 0 in the
channel specification
CSM = 1: FCS generation suppressed
ITD04579
FE=1 FNUM
Data
Contents
of
Frame 1 Frame 2
of
Contents
Data
7EHFrame 1 Frame 2
x Zero
Insertions
H
E7 . . . . . . 7 EH
y+1
[],max (FNUM - 0)y= x
8
x
8
---x
8
---
x
8
---
PEB 20320
Functional Description
User’s Manual 78 01.2000
Interrupts
The possible interrupts for the mode in transmit direction are:
HI: issued if the HI bit is detected in the transmit descriptor (not maskable)
FI: issued if the FE bit is detected in the transmit descriptor
(maskable by FIT in the channel specification)
ERR: one of the following transmit errors has occurred:
– the last descriptor had H = 1 and FE = 0
– the last descriptor had NO = 0 and FE = 0
(maskable by TE in the channel specification)
FO: one of the following transmit errors have occurred
– a BERR = ‘0’ was detected during a read access to a transmit data section for
this channel
– the MUN ICH 32 was u nab le to access the shared m em ory in ti me eit her for new
data to be sent or for a new transmit descriptor.
(maskable by TE in the channel specification)
typical data stream has the form
Example:
HDLC channel with
CS = 0) (FCS generated automatically)
INV = 0 (no inversion)
CRC = 0 (CRC16)
TRV = 00 (required as unused in HDLC mode)
FA = 1 (flag adjus tme nt)
MODE = 11 (HDLC)
IFTF = 1 (interframe time-fill ‘1’s)
INTEL interface
Channel number 1A
…ITF FLAG DATA FCS FLAG ITF …
PEB 20320
Functional Description
User’s Manual 79 01.2000
Figure 41
Note: 1. Data is transmitted according to §2.8 of CCIT T recommendation Q.921
2. Note: FCS in the data section is formatted as ordinary data!!!
3. FCS is generated here automatically as CS = 0 and CSM = 0 for the
1st descriptor.
4. There was 1 zero insertion in the 1st frame, so FNUM –=FNUM=2.
Therefore between the first and the second frame we have
FLAG ITF FLAG and ITF = FFH because IFTF = 1.
ITD04578
A0010002
AA
031 FFFFFFFF
80060801 80030800
31 0
Generate FI, HI-Int. 2000081A
31 0
31 0
31 0
31 0
2000181A Generate FI-Int.
1DATA
1 Desc
st nd
2 Desc 3 Desc
rd
0
1
FF
00
Address
Increases
FE=1
HOLD=0
HI=1
NO=1
CSM=0
FNUM=2 FNUM=1
CSM=1
NO=6
HI=0
HOLD=0
FE=1
01111110
.....
01010101 00010100010111110 01111110 11111111
FLAG
Time Increases
FLAG
3
ITF
Zero Insertion
FCS
2
5
FLAGFLAG
01111110
111110111110111110111110111110111110111110111110
01111110
DATA 28 Zero Insertion
4
011111100101010100010100010111110
FLAG
Zero Insertion
DATA 3
Generate FI-Int.
2000081A
FE=1
HOLD=0
HI=0
NO=3
CSM=1
FNUM=0
00 AAFA 28
00000000
1
8
---
PEB 20320
Functional Description
User’s Manual 80 01.2000
5. No FCS is generated here as CSM is ‘1’ for the second and third transmit
descrip tor. The FC S is suppos ed to be the last 2 by tes to be trans mitted in this
case, their validity is not checked internally.
6. There was 8 zero insertions in the 2nd frame, so FNUM –=FNUM–1=0.
Therefore between the second and the third frame we
have a shared FLAG.
For CS = 1 (CRC select) the transmitted da ta stream would differ at FCS, FCS wou ld just
be om itted.
For INV = 1 (chan nel in versio n) all bi ts of the data str eam (inc ludi ng FLAG, DATA, FCS,
ITF) would be inverte d.
For CRC = 1 (CRC 32) the transmitted data stream would only diffe r in the FCS, the FCS
would be 1101 0111 1010 0101 1000 0000 0010 0111.
For FA = 0 (no flag adjustment) the transmitted data stream would change only after
DATA 2. The value FNUM = 1 in the second descriptor would alone determine the
number of interframe time-fill characters, the scenario would look like
Figure 42
For IFTF = 0 (ITF flags) the transmitted data stream would only differ at ITF, the 8 ones
would be replac ed by 011 1 1110.
For Motorola interface the only difference is in the data section
For the first descriptor it ought to be
and for the second
and for the third
31 0
AA
31 0
FF FF FF FF
FF 00
31 0
AA 28 FA
8
8
---
DATA 2 FLAG FLAG DATA 3
0111 111 0111 111
PEB 20320
Functional Description
User’s Manual 81 01.2000
HDLC
Receive Direction
General Features
In receive direction:
1. The starting and ending flag (7EH before and after a frame) is recognized
and extracted.
2. A change of the interframe time-fill is recognized and reported by an interrupt.
3. The zero insertions (a ‘0’-bit after five ‘1’s within a frame) are extracted.
4. The FCS at the end of a frame is checked, it is (optionally) transferred to the shared
memory together with the data.
5. The number of the bits within a frame (without zero insertions) is checked to be
divisib le by 8.
6. The number of bytes within a frame is checked to be smaller than MFL + 1 (after
extraction of ‘0’ insertions).
7. The number of bits within a frame after extraction of ‘0’ insertions i s checke d
to be greater than (case NSF = 0 only)
8. The occurrence of an abort flag (7FH) ending a frame is checked.
More detailed description of the individual features:
1. a. A frame i s supposed to have s tarted if a fter a sequ ence of 0 111 1110 in the receive
data stre am ne ithe r FCH nor FDH nor 7E H has oc cu rred . The fram e i s s up pos ed to
have started with the first bit after the closing ‘0’ of the seque nce .
b. A frame is supposed to have stopped if a sequence of 0111 1110 or 0111 1111 is
found in the data stream after the frame has started. The last bit of the frame is
supposed to be the bit preceding the ‘0’ in the above sequences. The cases of
sequences 0111 1110 1111 111 and 0111 1110 0111 1111 are also supposed to
be frames of bit length –1 and 0 respectively.
A fr ame is also s upposed to ha ve st opped i f more than MFL byt es we re rec eived
sinc e the start of the frame and it wasn’t s topped ye t.
c. The ending flag of a frame may be the starting flag of the next frame (shared flags
supported).
(case NSF = 0 only) check a) 16 for CRC = 0
32 for CRC = 1
(only for CS = 0) check b) 32 for CRC = 0
48 for CRC = 1
(case NSF = 1 & CS = 1 only) check a’) 8 for CRC = x (ignored)
PEB 20320
Functional Description
User’s Manual 82 01.2000
2. The receiver is always in one of two possible interframe time-fill states:
to be called F and O.
The following diagram explains them.
A change from F to O and from O to F is reported by an IFC interrupt.
Figure 43
3. The ‘0’ extraction is also carried out for the last 6 bits before the stopping sequence.
4. The last 16 (CRC = 0) or 32 (CRC = 1) bits of a frame (after extraction of the zero
insertion s are sup posed to be the FCS of the remain ing bits of the frame. (For the case
of a frame with less than or equal to 16 or 32 bits respectively see discussion of 7).
The FCS is always checked, the check is reported in the CRCO bit of the last receive
descriptor of the frame
CRCO = 1: FCS was incorrect
CRCO = 0: FCS was correct.
5. The check is reported in the NOB bit in the last receive descriptor of the frame
NOB = 1: The bit length of the frame was not divisible by 8.
NOB = 0: The bit length of the frame was divisible by 8.
If NOB = 1: The last access to a receive data section of the frame may contain
erroneous bits and shouldn’t be evaluated.
6. The check is reported in the LFD bit in the last receive descriptor of the frame.
LFD = 1: The number of bytes was greater than MFL.
LFD = 0: The number of bytes was smaller or equal to MFL.
Only the bytes up to the
MFL + 1st one for CS =1
MFL – 1st one for CS = 0, CRC = 0
MFL – 3rd one for CS = 0, CRC = 1
are transferred to be stored memory. The bytes of the last access may be erroneous
and shouldn’t be evaluated.
ITD04577
RESET or Receive OFF
O
F
Receive Initialize
Channel Command
111111111111111
in the Data Stream
(15 contiguous "1"s
received) or a
Receive Abort Channel
Command during 15
received Bitssupported)
shared Zeros
received, Flags with
(2 contiguous Flags
in the Data Stream
0111111001111110
011111101111110 or
PEB 20320
Functional Description
User’s Manual 83 01.2000
7. For frames not fulfilling check a) no data are transferred to the shared memory
irrespective of CS.
Only an interrupt with the bit FI, SF and (possibly) ERR is generated.
For frames fulfilling check a) but not check b) data is transferred to the shared memory
but the SF bit in the last receive descriptor is set.
8. The check is reported in the RA bit in the last receive descriptor of the frame
RA = 1: The frame was stopped by the sequence 7FH
RA = 0: The frame was not stopped by the sequence 7FH.
Note: A receive descriptor with RA = 1 may also result from a fast receive abort or a
receive a bort channe l command or from a receive de scriptor with set HOLD bi t.
Options
The different options for this mode are:
–The kind of Frame Check Sequence (FCS)
Two kinds of FCS are implemented and can be chosen by CRC bit.
CRC = 0: the generator polynomial x16 +x
12 +x
5+ 1 is used (2 byte FCS of
CCITT Q.921)
CRC = 1: the generator polynomial
x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (4 byte FCS) is
used.
–the transfer of the FCS together with the recei ved data is progra mmable by the CS bit.
CS = 0: FCS is not transferred to the data section
CS = 1: FCS is transferred to the data section.
Note: FCS is always checked irrespective of the CS bit.
Interrupts
The possible interrupts for the mode in receive direction are:
HI: issued if the HI bit is detected in the receive descriptor (not maskable)
FI: issued if a received frame has been finished as discussed in 1.b of the protocol
features (also fo r frames which do not lead to data transfer as discussed in 7. of the
protocol feature s)
(maskable by FIR in the channel spec.)
IFC: issued if a change of the interf rame tim e-fill state as di scus sed in 2. has occurre d.
(maskable by IFC in the channel spec.)
SF: a frame not fulfilling check a) has been detected (maskable by SFE in the
channel spec.)
PEB 20320
Functional Description
User’s Manual 84 01.2000
ERR: issued if one of the following error conditions has occurred:
–FCS was incorrect
–the bit length was greater than MFL
–the frame was stopped by 7FH
–the frame could only be partly stored because of internal buffer overflow of RB
–a fast receive abort channel command was issued
–a receive abort channel command was detected during reception of a frame
–a frame could only be partly transferred to the shared memory because of a
receive descriptor with HOLD bit set
(maskable by RE in the c hannel spec.)
FO: issued if due to inaccessibility of internal buffer RB
–one ore more complete frames have been lost
–one ore more changes of interframe time-fill state were lost
(maskable by RE in the c hannel spec.)
Example:
HDLC channel with
CS = 1 (FCS transferred to shared memory)
INV = 0 (no inversion)
CRC = 1 (CRC 32)
TRV = 00 (required as unused in HDLC mode)
FA = x (irrelevant)
MODE = 11 (HDLC)
IFTF = x (irrelevant)
Motorola interface
Channel No. 1D
MF L = 10
PEB 20320
Functional Description
User’s Manual 85 01.2000
Figure 44
ITD04576
031
20080000
031
nd
2 Desc
40080000
8800203D
C0031C00
1 Desc
st
000C0000
31 0
Last Access of
a LFD Frame
Generate HI-Int.
031
CRCO,
NOB,
Generate FI, ERR-Int.
8800123D
should be Ignored
C2 A1 01 03
39 80 3D BC
DATA 2
LFD
4
..... 01111110 1000 0101 1000 0000 1100 0000 1001 1100 0000 00010100 0011
11010011 0100001010111101001101101000001111100001110111100
01111111
1
FLAG DATA 1, FCS 1
2
DATA Ignored up to next Flag
Abort Sequence
3
5
PEB 20320
Functional Description
User’s Manual 86 01.2000
Figure 45
ITD04575
031
200C0000
031
rd
3 Desc
C0080000
8800303D
C0081800
4 Desc
th
000C0000
31 0
Last Access of
a NOB Frame
Generate FI, HI-Int.
031 FB49AC00
CRCO,
NOB
Generate FI, ERR-Int.
8800123D
should be Ignored
00 AC 49 FB
C0 A4 F2 FA
DATA 2
FCS 2 DATA 3
01111110 0011 0101 1001 0010 1101 1111 00000 0000
FLAG DATA 2
6
2FCS
00110000 0111101011111010001010010
0011 0101 1001 0010 1101 1111 00000 0000
DATA 3FLAG
01111110
0010 0101 0100 1111 0101 11110000 0011
FCS 3
01111110
FLAG
Zero Insertion
(shared)
Zero Insertion
Zero Insertion
Zero Insertion Missing
PEB 20320
Functional Description
User’s Manual 87 01.2000
Figure 46
Note: 1. After Receive Initialization is detected all data are ignored until a flag is
received. The receiver is in the interframe time-fill state ‘0’.
2. After MFL + 1 data bytes are received the further data are ignored (except for
a change of the interframe time-fill state) and are neither stored in the RB nor
reported to the shared memory. The receiver waits for the next flag.
3. Even the abort sequence at the end of the frame will not lead to the RA bit in
the descriptor to be set.
4. Data are formatted according to §2.8 of CCITT Q.921.
5. The FCS is formatt ed as ordi nary data! !!
ITD04574
000C0000
AA 7B A5 01031 01A57BAA
00140000
31 0
(15 1)
8800083D
31 0
31 0
8800143D
Generate short
FCS 4
5 Desc
th th
6 Desc
C0050200C0050000
RA
8
1 1111
DATA Ignored up to next Flag
7
15
E4 XX XX XXXXXXXXE4
10
DATA 4
Generate IFC-Int.
8800083D
Generate IFC-Int.
8800123D
8800103D
Generate FI-Int.
Generate FI, ERR-Int.
(2 Flags)
9
Frame
Interrupt for FCS 5 *
11
1111110101000110011100111010 0111 011101111 1111
x "1"
5
1010 0101 1000 0000 0010 01111101 1110
DATA 4
5FCS
00000000 000000000000000000000000
0101 0101
FCS 4
0111 1110 111 1110
2 Flags with shared 0 FLAG
01111110
01010101
6DATA
01111110
FLAG FCS 6
01111111
Abort Sequence
1101 1110 1010 0101 1000 0000 0010 0111
Generate Short Frame Interrupts
8800163D
8800163D
011111100011111101111111
12
PEB 20320
Functional Description
User’s Manual 88 01.2000
6. LFD is issued and always accompanied by NOB.
CRCO shouldn’t be interpreted for a LFD frame.
7. Here the ending flag of the second frame is the starting flag of the third frame.
8. After an abort sequence data is ignored until a flag is found (except for a
change of the interframe time-fill state). They are neither stored in the RB nor
reported to the shared memory.
9. The last 3 by tes in the last w rite ac cess to the rece ive dat a sect ion of the 5th
descriptor have to be ignored.
10.The 2 flags with a shared 0 in the middle change the original interframe time-
fill state ‘0’ of the receiver to ‘F’. Th e 2 fla gs fo llo wing FC S 5 on th e o ther hand
do not change the interframe time-fill state, as it already was ‘F’.
11.The frame consisting only of 32 times 0 between 2 flags does not pass
check a). It only leads to an interrupt.
12.The 15 ב1’ leads to a change of the interframe time-fill state from ‘F’ to ‘0’ even
through it is in a data ignored zone.
13.This frame of length –1 leads to an interrupt.
For CS = 0 (CRC not select) the descriptor would have looked like
Figure 47
ITD04572
031
20080000
031 0301A1C2
st
1 Desc
C0071C00
HI,
8800323D 8800303D
Generate HI,
C0040000
Desc3
rd
00 AC 49 FB
31 0
200C0000
31 0
Last Access of a LFD Frame
should be Ignored
2
FI-Int.
Generate
FI, ERR-Int.
1
PEB 20320
Functional Description
User’s Manual 89 01.2000
Figure 48
Note: 1. Only the 7 leading bytes are reported (the last 4 are supposed to be the FCS
even in this case).
2. It is assumed here for convenience that the first descriptor points to the third
and not to the second descriptor as in the original example.
For INV = 1 (channel inversion) all bits of the data stream (including DATA, FCS, flag,
abort seq uence 15 ב1’) are interprete d inve rsely . e.g. ‘1000 0001’ would be interp reted
as flag 15 ב0’ would lead to a change from interframe time-fill state ‘F’ to ‘0’ etc.
ITD04573
031
000C0000
031
th
4 Desc
C0041800
8800123D
C0014000
5 Desc
th
000C0000
31 0
C0014200
6 Desc
th
AA XX XX XX
31 0
00140000
31 0
SF
Last Access of a NOB Frame
should be Ignored
Generate FI, ERR-Int.
031 XXXXXXAA
CRCO, NOB SF, RA
Interrupts as in
the original Example
PEB 20320
Functional Description
User’s Manual 90 01.2000
For CRC = 0 (CRC 16) the correct FCS e.g. zeros for DATA 4 would be
00001 0100 0101 1110 the 5th des c riptor would then be
Figure 49
For Intel interface the only difference is in the receive data sections. They would be
Figure 50
ITD04570
031
000C0000
031 XXFA28AA
th
5 Desc
C0034000
ITD04571
03 01 A1 C2
031 FB 49 AC 00
31 0 031 AA7BA501
1
st
Desc 3
rd
Desc
th
5 Descof of of
XX XX XX E4C0A4F2FA398030BC
PEB 20320
Functional Description
User’s Manual 91 01.2000
TMB
Transmit Direction
General Features
In transmit direction:
–The starting and ending flag (00H before and after a frame)
–The interframe time-fill between frames
is generated automatically.
Options
The different options for this mode are:
–The number of interframe time-fill characters as shown in Figure 26 by choosing
FNUM in the transmit descriptor. For the values FNUM = 0, 1, 2 we have
FNUM = 0 … frame 1, 00H, frame 2 … (start = end flag)
FNUM = 1 … frame 1, 00H, 00H, frame 2 …
FNUM = 2 … frame 1, 00H, 00H, 00H, frame 2 …
Interrupts
The pos sible interrup ts for t he mod e in tra nsmit di rectio n ar e iden tical t o those o f HD LC.
A typical data stream has the form
ITF DATA ITF DATA
Example
TMB channel with
INV = 0 (no inversion)
CRC = 0 (re qui red)
TRV = 00 (required)
FA = 0 (required)
MODE = 01 (TMB)
IFTF = 0 (required)
Intel interface
Channel number 5
PEB 20320
Functional Description
User’s Manual 92 01.2000
Figure 51
Note: 1. Data is transmitted according to Q.921 §2.8 and fully transparent.
2. A transmit descriptor with NO = 0 and FE = 1 is allowed, one with NO = 0 and
FE = 0 is forbidden.
3. FNUM = 1 leads to 2 FLAGS after DATA 2.
ITD04569
20020000
0
CE AB
031
80000000 80030001
45 23 01
31 0
Generate FI-Interrupt
88001005
31 0 31 0
31 0
88002005
Generate HI-Interrupt
0
0024A0C800735D00 ..........
DATA 21DATA
1
88001005
Generate FI-Interrupt
FLAG FLAG
00
2 FLAGS
2 3
PEB 20320
Functional Description
User’s Manual 93 01.2000
TMB
Receive Direction
General Features
1. The starting and endin g flag (00 H bef ore and aft er a frame) as well as i nterframe tim e-
fill is recognized and extracted.
2. The number of bits within a frame is checked to be divisible by 8.
3. The number of bytes within a frame is checked to be smaller than MFL + 1.
4. A frame containing less than 8 bits may be ignored completely by the receiver.
More detailed description of the individual features:
1. a. A frame is supposed to have started if after a sequence ‘0000 0000’ a ‘1’-bit is
recognized. The frame is supposed to have this ‘1’-bit as first bit.
b. A frame is supposed to have stopped if
–either a sequence 0000 0000 1 is found in the data stream after the frame has
started
–or a sequence 0000 0000 is found octet synchronous (i.e. the first bit of the
sequenc e 00H is the 8 m + 1st bit si nce th e starti ng ‘1’-bit of 1.a. for an integer m).
In both cases the last bit before the sequence 00H is supposed to be the last bit of the
frame.
2. The check is reported in the NOB bit in the last receive descriptor of the frame.
NOB = 1: The bit length of the frame was not divisible by 8.
NOB = 0: The bit length of the frame was divisible by 8.
3. The check is reported in the LFD bit in the last receive descriptor of the frame.
LFD = 1: The number of bytes was greater than MFL.
LFD = 0: The number of bytes was smaller or equal to MFL.
Only the bytes up to the MFl + 1st o ne are transferre d to the sh ared memory. The bytes
of the las t a cces s t o the receiv e d ata section of the fram e may contain erron eous bits
and shouldn’t be evaluated. LFD is always accompanied by NOB.
Options
There are no options in receive direction for this mode.
PEB 20320
Functional Description
User’s Manual 94 01.2000
Interrupts
The possible interrupts for the mode in receive direction are:
HI: issued if HI bit is detected in the receive descriptor (not maskable).
FI: issued if a received frame has been finished as discussed in 1b) of the protocol
features or a receive abort channel command was detected during reception of a
frame.
(maskable by FIR in the channel spec.)
ERR: issued if one of the following error conditions has occurred
– the bit length of the frame was not divisible by 8
– the byte length was greater than MFL
– the frame could only be partly stored because of internal buffer overflow of RB
– a fast receive abort channel command was issued
– the frame could only be partly transferred due to a receive descriptor with set
HOLD bit.
(maskable by RE in the channel specification)
FO: issued if due to inaccessibility of the internal buffer RB one or more complete
frames have been lost. (maskable by RE in the channel spec.)
Example:
TMB channel with
INV = 0 (no inversion)
CRC = 0 (required)
TRV = 00 (required)
FA = 0 (required)
MODE = 01 (TMB)
IFTF = 0 (required)
MFL = 7
Motorola interface
Channel No. A
PEB 20320
Functional Description
User’s Manual 95 01.2000
Figure 52
ITD04568
00040000
9D 01 XX XX
031 XXXXXXD3
200C0000 20080000
31 0
Generate FI,
8800302A
31 0
31 0
31 0
31 0
8800102A
Generate FI-Int.
DATA 3
1DATA DATA 2
1
st
Desc Desc
nd
23
rd
Desc
8800322A
C0020800C0010000C0020000
NOB
2
HI-Int. HI,Generate FI, ERR-Int.
Last Access of a NOB Frame
should be Ignored
11110111 01010101 0000 0000 0000 10101101 00101010 0000 0000
DATA Ignored
up to next Framestart
5
FLAG FLAGDATA 5
DATA 4
1000000010111100 0000000 11111110 01111111 11111011 11010101 01001100
10100000
FLAG
synchronous
non octet
4
00000000 10111001 10000000 00000000 00
3
11001011 00000000 10000000
DATA 1 DATA 2 DATA 3
FLAG FLAG FLAG
octet
synchronous
octet
synchronous
1
(start) FLAG
PEB 20320
Functional Description
User’s Manual 96 01.2000
Figure 53
Note: 1. After Receive Initialization is detected all data are ignored until the starting
sequence 0000 0000 1 is detected.
2. Data are formatted according to §2.8 of CCITT Q.921.
3. The oc tet sy nc hro nou s (en d) fla g of one fram e can be part of the (st art) fla g of
the next frame. Between DATA 1 and DATA 3 they are identical (shared flags
supported).
4. Here the sequence 0000 0000 1 is detected non-octet synchronously.
Theref ore the fram e belonging to DATA 3 is s upposed to have ende d non-octet
synchronously (NOB set in the 3rd descriptor).
5. After MF L + 1 data bytes the fu rthe r data are ig nore d an d are neither stored in
the RB nor reported to the shared memory. The receiver waits for the next
sequence 0000 0000 1 to come.
6. If a receive descriptor is full (4th desc.) the MUNICH32 branches to the next
receive descriptor (5th desc.) even if no further data are to be given to the
shared memory.
ITD04567
031
20080000
031 DFFE7F01
DATA 4
th
4 Desc
40080000
Generate HI-Int.
8800202A 8800122A
C0000C00
Desc5
th
00040000
31 0
8800102A
Generate FI-Int.
C0020000
Desc6
th
B5 54 XX XX
31 0
00FC0000
31 0
LFD,
Last Access of a LFD Frame
should be Ignored
Generate FI,
6
NOB
ERR-Int.
DATA 5
PEB 20320
Functional Description
User’s Manual 97 01.2000
For INV = 1 (channel inversion) all bits of the data stream (including DATA, FLAG) are
interpreted inversely e.g. 1111 1111 0 would be interpreted as starting sequence then.
For Intel interface the only difference is in the receive data sections. They would be
Figure 54
ITD05034
XX XX XX D3
031 DF FE 7F 01
31 0 031 B554XXXX
of 2 Desc
nd
of 4 Desc
th th
of 6 Desc
st
of 1 Desc
31 0
9D01XXXX
PEB 20320
Functional Description
User’s Manual 98 01.2000
TMR
Transmit Direction
Genera l Features
In transmit direction
–the starting and ending flag (00 00H or 0 00H between frames) is generated
automatically.
Options
The different options for this mode are
–the number of interframe time-fill characters as shown in Figure 29 by choosing
FNUM in the transmit descriptor. For the values 0, 1, 2 we have
FNUM = 0 … frame 1, 000H, frame 2 …
FNUM = 1 … frame 1, 00H, 00H, frame 2 …
FNUM = 2 … frame 1, 00H, 00H, 00H, frame 2 …
By choosing FNUM = 0 and setting the last transmitted nibble in the transmit data section
to 0H frames of effective length n + 1/2 bytes can be sent as required by GSM 08.60.
Interrupts
The possible interrupts for the mode in the transmit direction are identical to those of
HDLC.
A typical data stream has the form
ITF DATA ITF DATA
Example:
TMR channel with
INV = 0 (no inversion)
CRC = 1 (required)
TRV = 00 (required)
FA = 0 (required)
MODE = 01 (TMR)
IFTF = 0 (required)
Intel interface
Channel No. 5
PEB 20320
Functional Description
User’s Manual 99 01.2000
Figure 55
Note: 1. Data is transmitted according to Q.921 §2.8 and fully transparent.
2. A transmit descriptor with NO = 0 and FE = 1 is allowed, one with NO = 0 and
FE = 0 is forbidden.
3. FNUM = 1 leads to 2 FLAGS after DATA 2.
ITD04566
20020000
0
0E AB
031
80000000 80030001
45 23 01
31 0
Generate FI-Interrupt
88001005
31 0 31 0
31 0
88002005
Generate HI-Interrupt
0
0024A0C800705D00 ..........
DATA 21DATA
1
88001005
Generate FI-Interrupt
FLAG FLAG
00
2 FLAGS
2 3
Frame of Effective
Length 1 Byte/2
1
PEB 20320
Functional Description
User’s Manual 100 01.2000
TMR
Receive Direction
Genera l Features
1. The starting and the ending flag (00 00H) is recognized. Interframe time-fill, both
characters of the starting flag and the last character of the ending flag is extracted.
2. The number of bits within a frame is checked to be divisible by 8.
3. The number of bytes within a frame is checked to be smaller than MFL.
More detailed description of the individual features
1. a. A frame is supposed to have started after a sequence of 16 zeros a ‘1’-bit is
recognized. The frame is supposed to have this ‘1’-bit as first bit.
b. A frame is supposed to have stopped if
–either a sequence of 16 ‘zeros’ and a ‘one’ is found in the data stream after the
frame has sta rted
–or a sequence of 16 zeros is found octet synchronous (i.e. the first bit of the
sequence 00 00H is the 8m + 1st bit since the starting ‘1’-bit of 1.a. for an
integer m).
In b oth c ases the e ighth bit of the s equen ce 00 00H is sup posed to be the l ast b it of
the frame.
2. The check is reported in the NOB bit in the last receive descriptor of the frame.
NOB = 1 the bit length of the frame was not divisible by 8.
NOB = 0 the bit length of the frame was divisible by 8.
If NOB = 1 the last b yte of t he l as t ac ce ss to a receive data se cti on of th e frame may
contain erroneous b its an d shouldn’t be evaluated. This does not affect the rece ption
of frames with n + 1/2 octets
3. The check is reported in the LFD bit in the last receive descriptor of the frame.
LFD = 1 the number of bytes was greater than MFL.
LFD = 0 the number of bytes was smaller or equal to MFL.
MFL + 1st one are tr ans ferr ed to the s ha red m em ory . The byt es of the last acce ss to
the receive data section of the frame may contain erroneous bits and shouldn’t be
evaluated.
LFD is always accompanied by NOB.
PEB 20320
Functional Description
User’s Manual 101 01.2000
Options
There are no options in receive direction for this mode.
Interrupts
The possible interrupts for the mode in receive direction are identical to those of TMB.
Example:
TMR channel with
INV = 0 (no inversion)
CRC = 1 (required)
TRV = 00
FA = 0
MODE = 01 (TMR)
IFTF = 0 (re qui red)
MFL = 7
Motorola interface
Channel No. 15
PEB 20320
Functional Description
User’s Manual 102 01.2000
Figure 56
ITD04565
00040000
9D 01 00 XX
031 XXXX00D3
200C0000 00080000
01 00 3D AF
31 0
Generate FI, HI-Int.
88003035
31 0
31 0
31 0
31 0
88001035
Generate FI-Int.
031
20080000
031 569AFB8F
DATA 4
DATA 3
1DATA DATA 2
1
st
Desc Desc
nd
23
rd
Desc
th
4 Desc
88001235
C0060800C0020000C0030000
03 XX XX XX
NOB
Last Byte of
a NOB Frame
should be Ignored
40080000
Generate HI-Int.
88002035 88003235
FI,
C0000C00
Desc5
th
20040000
31 0
88001035
Generate FI-Int.
C0030000
Desc6
th
BB 5E 00 XX
31 0
00080000
31 0
LFD,
Last Access of a LFD Frame
should be Ignored
Generate
6
5
NOB
HI, ERR-Int.
Generate FI, ERR-Int.
DATA 5
(end) FLAG
synchronousoctet
5DATA
11011101 01111010 00000000 00000000
4DATA
00000000000000001111111111011011110111011111011111110011
0110101011110001 11011111 01011001
0000
synchronous FLAG
non octet
00000000
2DATA
000000001100101100000000
2
(end) FLAG
00000000
(start) FLAG
.... 00000000 00000000
(start) FLAG
1
octet synchronous FLAG
1DATA
3
1000000010111001
000000001100000011110101101111000000000010000000
3DATA
4
up to next Framestart
DATA Ignored
0000
octet synchronous
PEB 20320
Functional Description
User’s Manual 103 01.2000
1. After receive initialization is detected all data are ignored until a starting sequence
(16 ‘zeros’, ‘one’) is detected.
2. The octet s ynchronous (end ) flag of one frame can b e part of the ( start) flag of the next
frame.
Note, that the first 00H character of the end flag is stored in the receive data section
as ordinary data and is included in BNO.
Between DATA 2 and DATA 3 the start and end flag are identical (shared flags
supported).
3. Here the start sequence is detected non-octet synchronously within a frame.
Therefore the frame belonging to DATA 3 is supposed to have ended non-octet
synchronously (NOB set in the 3rd descriptor).
4. After MFL + 1 d ata by tes the further data a re i gnored and are neithe r store d in the R B
nor reported to the shared memory.
5. Data are formatted according to §2.8 of CCITT Q. 921.
6. If a receive descriptor is full (4th descriptor) the MUNICH32 branches to the next
receive descr iptor (5th descrip tor) e ve n i f no fu rthe r da ta are to be given to th e s hare d
memory.
For INV = 1 (channel inversion) all bits of the data stream (including DATA, FLAG) are
interpreted inversely e.g. 16 ‘ones’, ‘zero’ is interpreted as starting sequence then.
For Intel interface the only difference is in the receive data sections. They would be
Figure 57
ITD05035
XX XX 00 D3
031 56 9A FB 8F
31 0 031 BB5E00XX
nd th th
of 1 Desc
st
31 0
9D0100XX
rd
031 01003DAF
XX XX XX 03
of 2 Desc of 3 Desc of 4 Desc of 6 Desc
PEB 20320
Functional Description
User’s Manual 104 01.2000
TMA
Transmit Direction
Genera l Features
In the transmit direction
–a slot-synchronous transparent data transmission
–a high impedance overwrite for the masked bits in the slot
–a programmable number of programmable fill characters between data
(also slot synchronous)
is generated automatically.
Options
The different options for this mode are
–The value of the fill-character can be programmed for FA = 1 in the channel
specifi cation. The fill-character (TC ) is then programmed in the TFLAG. Fo r FA = 0 the
fill character is FFH and TFLAG has to be set to 00H. If subchanneling is chosen (not
all fill/mask bits of the channel are ‘1’) FA must be set to ‘0’.
–The number of inter-data time-fill characters as shown in Figure 33 by choosing
FNUM = 0, 1, 2 we have
FNUM = 0 … DATA 1, TC, DATA 2 …
FNUM = 1 … DATA 1, TC, TC, DATA 2 …
FNUM = 2 … DATA 1, TC, TC, TC, DATA 2 …
Interrupts
The poss ible inte rrupts f or this mo de in trans mit direct ion are ide ntical to t hose of H DLC.
PEB 20320
Functional Description
User’s Manual 105 01.2000
Example 1:
(no subchanneling by fill/mask bits)
TMA channel with
TFLAG = B2H
INV = 0 (no data inversion)
CRC = 0 (re qui red)
TRV = 00 (required)
FA = 1 (flag filtering)
MODE = 00 (TMA)
IFTF = 0 (required)
All fill-mask bits are ‘1’ for this channel (no high impedance overwrite)
Intel interface
Channel no. D
Figure 58
Note: 1. Data are formatted according to §2.8 of Q.921. The TC is transmitted MSB
(bit 15) first though!!!
2. FNUM = 0 in the second descriptor leads to the insertion of the TC after
DATA 2, FNUM = 1 in the third descriptor to the insertion of 2 TCs.
ITD04564
20020000
0
XX XX D1 AB
031 361200XX
A0030000 80010001
XX XX XX F2
31 0
Generate HI-, FI-Interrupt
8800300D
31 0
31 0
31 0
31 0
8800200D
Generate HI-Interrupt
031
00030000
031 D12D32XX
000
DATA 4DATA 31DATA DATA 2
1st Desc Desc
nd
23
rd Desc th
4 Desc
4B
0707
4C8B
70
B2
7 0
B2
7 0
4F
7 0
B2
7 0
00
7 0
48
7 0
6CB85D
700
Boundaries
Time-Slot
Bit No 70 70
..........
DATA 21DATA 4DATADATA 3
12
TC 2 TCs
For INV=1 DATA and TC would be Inverted
PEB 20320
Functional Description
User’s Manual 106 01.2000
For INV = 1 the data stream would be inverted completely
Figure 59
For FA = 0 TF LAG has to be programmed to 00H and the data stream would be
Figure 60
For Moto rola m ode th e data secti ons l eading to the s am e d ata stream would have bee n
Figure 61
DATA 1 DATA 2 TC DATA 3 2 TCs DATA 4
…2A 74 93 B7 FF 4D B0 4D 4D 74 4B B3 …
DATA 1 DATA 2 TC DATA 3 2 TCs DATA 4
D5 8B 6C 48 00 FF 4F FF FF 8B B4 4C
ITD05036
36 12 00 XX
031 D1 2D 32 XX
31 0
th
of 1 Desc
st
31 0
XXXXD1AB
rd
031 XXXXXXF2
of 2 Desc
nd of 3 Desc of 4 Desc
PEB 20320
Functional Description
User’s Manual 107 01.2000
Example 2:
(subchanneling by fill/mask bits)
TMA channel with
TFLAG = 00H (required for this case)
INV = 0 (no data inversion)
CRC = 0 (required)
TRV = 00 (required)
FA = 0 (required for subchanneling)
MODE = 00 (TMA)
IFTF = 0 (re qui red)
Intel interface
Channel no. D
Figure 62
ITD04563
20020000
0
XX XX D1 AB
031 361200XX
A0030000 80010001
XX XX XX F2
31 0
Generate HI-Interrupt
8800200D
31 0
31 0
31 0
31 0
8800200D
Generate HI-Interrupt
031
00030000
031 D12D32XX
000
DATA 4DATA 31DATA DATA 2
1
st
Desc Desc
nd
23
rd
Desc
th
4 Desc
PEB 20320
Functional Description
User’s Manual 108 01.2000
Figure 63
Note: Example 2 uses the same descriptors as example 1. Those bits in the data stream
that are at places where fill/mask is ‘zero’ are overwritten by ‘Z’ i.e. high
impedance. In all other protocols bits of the data stream are not overwritten by
fill/mask zero bits.
Instead the whole data stream is sent at fill/mask one bits for all other protocols.
ITD04562
01234567
Slot Boundaries
Fill/Mask
High Imp. Overwrite
External Data
Internal Data
1110111
11
1111Z1
1101
10 1 0 0
1
7654321076543210765432107654321076543210
Bit No
10 111 11
Z
1
0000
Z0
1
1
1
1
1
1
111110
01
0Z
DATA 3 (4F) B4(8B4DATATCs 4C)
11 1 0 0
00ZZ11111
00 111111111111
111 11110
Z
1010011
ZZZ111
10111111
1111 0001 11 110
111 111
1
00
0000
000
1
(FF FF)2
ITD04561
01234567
Slot Boundaries
Fill/Mask
High Imp. Overwrite
External Data
(TDATA)
Internal Data
10101000001111
1111
Z1101Z10ZZ1Z
0110010
110101011 0111010100
011 1
7654321076543210765432107654321076543210
Bit No
111010 1
0
11 11 1
000
00
000
000
ZZZZZZZ0
111
000000 000
Z010Z Z Z00 0000
1
11
1
1
1
1
1
1
1
1
1
1
1
1
1
11100
011
0ZZ
DATA 1 (D5 8B) 48(6C2DATA TC (FF)00)
PEB 20320
Functional Description
User’s Manual 109 01.2000
TMA
Receive Direction
General Features
In the receive direction
–a slot synchronous transparent data reception
–a ‘1’ overwrite for masked bits in the slot
–for FA = ‘1’ a slot synchronous programmab le flag extraction
is pe rformed auto matically.
Options
The different options for this mode are:
–the programmable character TC to be extracted for FA = ‘1’ is TFLAG. For FA = ‘0’
nothing is extracted. If subchanneling is chosen (not all fill/mask bits of the channel
are ‘1’) FA must be set to ‘0’.
Interrupts
The possible interrupts for the mode in receive direction are:
HI: issued if the HI bit is detected in the receive descriptor (not maskable).
ERR: issued if a fast receive abort channel command was issued.
(maskable by RE in the channel spec.)
FO: issued if data could only partially stored due to internal buffer overflow of RB.
(maskable by RE in the channel spec.)
Example 1:
(no subchanneling)
TMA channel with
TFLAG = D7
INV = 0 (no channel inversion)
CRC = 0 (re qui red)
TRV = 00 (required)
FA = 1
MODE = 00 (TMA)
IFTF = 0
Motorola interface
Channel No. E
PEB 20320
Functional Description
User’s Manual 110 01.2000
Figure 64
Note: The FE bit is never set in a receive descriptor.
The data are formatted according to §2.8 Q.921.
For FA = 0 (and therefore TFLAG = 00H)
The descriptor would be
Figure 65
ITD04560
00040000
40040000
6B F5 BD 00031 1EBEC614
40040000
20040000
31 0
Generate HI-Interrupt
8800202E
31 0
31 0
Slot
Boundaries 007
D6 D7 FA
07
DB
07
00
07
7D
07
7D
07
82
07
36
07
7D 87
70 70
7D
Octet
Synchr.
TC TCs
Synchr.
2 Octet
TC
Synchr.
Octet Not
Octet
Synchr.
TC not Filtered
ITD04559
00040000
40040000
6B EB F5 BD
031 14EBEB00
40040000
20040000 00040000
40040000
C6 EB BE 1E
31 0
Generate HI-Interrupt
8800202E
31 0
31 0
31 0
31 0
PEB 20320
Functional Description
User’s Manual 111 01.2000
For INV = 1 the receiver filters the inverse of the TFLAG as TC out of the data stream
and inverts the data (only the octet synchronous 28H would be filtered).
For Intel interface the data sections would be
for the first descriptor and
for the second.
Example 2:
(with subchanneling)
TMA channel with
TFLAG = 00H (required becau se of sub ch ann eli ng)
INV = 0 (no channel inversion)
CRC = 0 (required)
TRV = 00 (required)
FA = 0 (required because of subchanneling)
MODE = 00 (TMA)
IFTF = 0
Motorola interface
Channel No. E
00 BD F5 6B
1E BE C6 14
PEB 20320
Functional Description
User’s Manual 112 01.2000
Figure 66
ITD04558
11
00040000
40040000
00 EF F7 D6
031
111111010011000101100010111101
Slot Boundaries
Fill/Mask
"one" Overwrite
External Data
(RDATA)
Internal Data
For INV=1
100101001001011101100110
1111111
101111011011011111111
00000000
000000001 110 111 10 11101 100
11 0111 1 0110
31 0
PEB 20320
Functional Description
User’s Manual 113 01.2000
V.110/X.30
Transmit Direction
General Features
In transmit direction
–the synchronization pattern for V.110/X.30 frame as shown in Table 1.
–the framing for the different data rates with programmable E-, S-, X-bits
–sending ‘0’ before all frames
is pe rformed auto matically.
Table 1
Synchronization Pattern for V.110/X.30-Frames
The E-, S-, X-bits are fed into the data stream by special transmit descriptor (as shown
in Figure 30), they can only cha nge from one 10 -octet fra me to the next , not withi n a 10-
octet frame.
The data from the data sections are supposed to come in the form:
31 0
1 1 B6 B5 B4 B3 B2 B1 1 1 B12 B11 B10 B9 B8 B7 1 1 B18 B17 B16 B15 B14 B13 1 1 B24 B23 B22 B21 B20 B19
(for Motorola mode),
31 0
1 1 B24 B23 B22 B21 B20 B19 1 1 B 18 B17 B 16 B15 B14 B 13 1 1 B12 B11 B 10 B9 B 8 B7 1 1 B6 B 5 B4 B3 B2 B1
(for Intel mode).
where for 600 bit/s e.g. B1 to B6 belong to the first 10-octet frame, B7 to B12 belong to
the second 10-octet frame, etc.
Octet No.12345678
1
2
3
4
5
6
7
8
9
10
00000000
1
1
1
1
1
1
1
1
1
PEB 20320
Functional Description
User’s Manual 114 01.2000
Options
The different options for this mode are:
–the framing pattern, as shown in Table 2 to Table 5, is programmed by the bits TRV.
Interrupts
HI: issued if the HI bit is detected in the transmit descriptor (not maskable)
ERR: if one of the following transmit errors has occurred
– the last descriptor had FE = 1 (leads to an abort of the transmit data,
see Figure 31)
– the last descriptor had H = 1 (see Figure 29)
– the last descriptor had NO = 0
(maskable by TE in the channel spec.)
FO: one of the following transmit errors has occurred
– a BERR = ‘0’ was detected during a read access to a transmit data section for
this channel
– the MUN IC H32 w as una ble to ac ce ss the s hare d me mory in time ei ther for new
data to be sent or for a new descriptor.
(maskable by TE in the channel spec.)
PEB 20320
Functional Description
User’s Manual 115 01.2000
Example
X.30/V110 channel with
CS = 0 (required)
INV = 0
CRC = 0
TRV variable (all values shown in examples)
FA = 0 (required)
MODE = 10 (V.110/X.30)
Intel interface
Channel No. 1F
Figure 67
Note: The first transmit descriptor must have the V.110-bit set.
ITD05037
00028000
0
75 40 00 00031 C3D6FAXX
20030000 20018000
8A 80 00 00
31 0
Generate HI-Interrupt
8800201F
31 0
31 0
31 0
31 0
031
00030000
031 C0E2D1XX
000
DATA 2E, S, X 21E, S, X DATA 1
880201F
Generate HI-Interrupt
PEB 20320
Functional Description
User’s Manual 116 01.2000
TRV = 00
0000 0000
1111 1110
1111 1111
1111 1000
1000 0001
1010 1110
1000 0000
1000 0001
1000 0000
1000 0001
0000 0000
1000 0000
1001 1111
1111 1110
1111 1111
1010 1110
1000 0000
1001 1111
1111 1000
1000 0001
0000 0000
1000 0000
1001 1111
1111 1000
1000 0001
1010 1110
1111 1110
1111 1111
1111 1110
1111 1111
0000 0000
1000 0001
1000 0000
1000 0001
1000 0000
1101 0001
1000 0001
1000 0000
1000 0001
1000 0000
0000 0000
1000 0001
1001 1110
1111 1001
1000 0000
1101 0001
1000 0001
1000 0000
1000 0111
1111 1110
0000 0000
1111 1111
1110 0000
1000 0001
1000 0000
1101 0001
1000 0001
1001 1110
1111 1001
1000 0000
D6 = 11 0 1 0 1 1 0
B6B5B4B3B2B1
FA = 11 1 1 1 0 1 0
B6B5B4B3B2B1
Change of E-, S-, X-bits
SA
X
SB
1 E1E2E3E4E5E6E7
PEB 20320
Functional Description
User’s Manual 117 01.2000
TRV = 01
TRV = 10
0000 0000
1111 1110
1110 0001
1000 0000
1000 0001
1010 1110
1000 0110
1111 1111
1000 0110
1110 0001
0000 0000
1000 0110
1110 0001
1111 1110
1111 1111
1010 1110
1000 0000
1000 0001
1000 0000
1000 0001
0000 0000
1000 0111
1110 0000
1000 0001
1001 1110
1101 0001
1111 1001
1000 0000
1000 0111
1110 0000
E2 = 1 1 1 0 0 0 1 0
B6B5B4B3B2B1
D1 = 1 1 0 1 0 0 0 1
B6B5B4B3B2B1
Change of E-, S-, X-bits
FA (last byte of DATA 1)→ 1 1 1 1 1 0 1 0
B6B5B4B3B2B1
1 1 0 0 0 0 0 0
B6B5B4B3B2B1
C0 (first byte of DATA 2) →
SA
X
SB
1 E1E2E3E4E5E6E7
0000 0000
1111 1000
1000 0001
1001 1110
1001 1001
1010 1110
1001 1000
1111 1111
1000 0000
1000 0001
0000 0000
1001 1001
1000 0110
1110 0001
1001 1000
1101 0001
11
10
11
10
SA
X
SB
1 E1E2E3E4E5E6E7
E2 = 1 1 1 0 0 0 1 0
B6B5B4B3B2B1
D1 = 1 1 0 1 0 0 0 1
B6B5B4B3B2B1
Change of E-, S-, X-bits
PEB 20320
Functional Description
User’s Manual 118 01.2000
TRV = 11
For INV = 1 (channe l inversion) all bits are inverted. For Mo torola mode the data sections
would have to have the form to yield the same output data.
Figure 68
0000 0000
1110 0000
1011 0101
1010 1110
1000 0001
1010 1110
1010 0010
1100 0101
10
11
Change of E-, S-, X-bits
ITD05038
C3 86 FA XX
031 C0 E2 D1 XX
31 0
DATA 1E, S, X 1 31 0
75400000 E, S, X 2 031 8A800000
XX XX 00 03 DATA 2
PEB 20320
Functional Description
User’s Manual 119 01.2000
V.110/X.30
Receive Direction
General Features
In receive direction
–the starting sequence (00H followed by a ‘1’-bit) after initialization of
loss of synchro nism is det ected.
–the synchronization pattern is monitored, after 3 consecutive
erroneous frames a loss of synchronism is detected.
–a change of E-, S-, X-bits is monitored and reported by an interrupt.
–the data bits are extracted and written into the data section.
More detailed description of the individual features:
1. and 2. the receiver can be in one of 2 states:
Figure 69
Data ex traction and monito ring of a ch ange of E-, S-, X-bi ts and sy nchroniz ation pattern
is only performed in synchronized state.
In the as ync hro no us s ta t e th e rec ei ver wait s for the sync hron iz ati on p atte r. Th e ‘1’-b it i s
then interpreted as bit 1 of octet 2.
3. During the syn chronize d state a ch ange of E, S, X-bits from one frame to the next and
even within a frame (for SA, SB bits) is monitored. Only one interrupt per frame is
reported e ve n i f SA e. g. ch ang es 3 tim es wi thi n t he frame. Th e E-, S-, X-bits rep orte d
in the interrupt are S9 for SB and S8 for SA and the second occurrence of X for X.
4. The bits written into the data section are marked by O in Table 2 to Table 4. As
shown, bits repeated in the serial data are only strobed than at their last instance.
ITD05039
RESET
Unsynchronous State
Synchronous State
3 Consecutive Erroneous Frames
(with a Frame Error)by a "1" bit
8 * "0" bit followed
PEB 20320
Functional Description
User’s Manual 120 01.2000
Table 2
Framing for Networks with 600-bit/s Data Rate
Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set
Octet No.12345678
1
2
3
4
5
6
7
8
9
10
00000000
1 B1B1B1B1B1B1S1
1 B1B1B2B2B2B2X
1 B2B2B2B2B3B3S3
1 B3B3B3B3B3B3S4
1 E1E2E3E4E5E6E7
1 B4B4B4B4B4B4S6
1 B4B4B5B5B5B5X
1 B5B5B5B5B6B6S8
1 B6B6B6B6B6B6S9
Table 3
Framing for Networks with 1200-bit/s Data Rate
Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set
Octet No.12345678
1
2
3
4
5
6
7
8
9
10
00000000
1 B1B1B1B1B2B2S1
1 B2B2B3B3B3B3X
1 B4B4B4B4B5B5S3
1 B5B5B6B6B6B6S4
1 E1E2E3E4E5E6E7
1 B7B7B7B7B8B8S6
1 B8B8B9B9B9B9X
1 B10 B10 B10 B10 B11 B11 S8
1 B11 B11 B12 B12 B12 B12 S9
PEB 20320
Functional Description
User’s Manual 121 01.2000
They are grouped together in the form:
31 0
1 1 B6 B5 B4 B3 B2 B1 1 1 B12 B11 B 10 B9 B8 B7 1 1 B18 B17 B16 B15 B1 4 B13 1 1 B2 4 B23 B22 B21 B20 B19
(for Motorola mode)
31 0
1 1 B24 B23 B22 B21 B20 B19 1 1 B18 B17 B16 B15 B14 B13 1 1 B12 B11 B10 B9 B8 B7 1 1 B6 B5 B4 B3 B2 B1
(for Intel mode)
where for the 600 bit /s e.g. B1 to B6 belong to the firs t 10-octe t frame, B7 to B12 belon g
to the second 10-octet frame etc.
Table 4
Framing for Networks with 2400-bit/s Data Rate
Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set
Octet No.12345678
1
2
3
4
5
6
7
8
9
10
00000000
1 B1B1B2B2B3B3S1
1 B4B4B5B5B6B6X
1 B7B7B8B8B9B9S3
1 B10 B10 B11 B11 B12 B12 S4
1 E1E2E3E4E5E6E7
1 B13 B13 B14 B14 B15 B15 S6
1 B16 B16 B17 B17 B18 B18 X
1 B19 B19 B20 B20 B21 B21 S8
1 B22 B22 B23 B23 B24 B24 S9
Table 5
Framing for Networks with 4800-, 9600-, 19200-, 38400-bit/s Data Rate
Intermediate Rate = 8, 16, 32, 64 Kbit/s, i.e. Subcha nnelling with 1, 2, 4 , 8 Fill/Mask
Bit Set
Octet No.12345678
1
2
3
4
5
6
7
8
9
10
00000000
1 B1B2B3B4B5B6S1
1 B7B8B9B10B11B12X
1 B13 B14 B15 B16 B17 B18 S3
1 B19 B20 B21 B22 B23 B24 S4
1 E1E2E3E4E5E6E7
1 B25 B25 B27 B29 B29 B30 S6
1 B31 B32 B33 B35 B35 B36 X
1 B37 B36 B39 B41 B41 B42 S8
1 B43 B44 B45 B47 B47 B48 S9
PEB 20320
Functional Description
User’s Manual 122 01.2000
Options
The different options for this mode are the framing pattern as shown in Table 2 to
Table 5 is programmed by the bits TRV.
Interrupts
The possible interrupts for this mode are
FRC: issued if the receiver has detected a change of S-, X-, E-bits; the value of the bits
E7, …, E1, S8 for SA and S9 for SB and th e second occu rrence of X within the 1 0-
octet frame is reported within the same interrupt.
(maskable by CH in the channel specification
HI: issued if the HI bit is detected in the transmit descriptor (not maskable).
ERR: issued if one of the following receive errors has occurred:
– a fast receive abort channel command was issued (this leads to a setting of the
RA bit in the status byte)
– data could only partly be stored due to internal buffer overflow of RB
– 3 consecutive frames had an error in the synchronization
pattern (loss of synchronism)
– the H OLD bit in the recei ve desc riptor wa s detecte d (this le ads to a setting of the
RA bit in status in the receive descriptor).
(maskable by RE in the channel specification)
FO: issued if due to inaccessibility of the internal buffer (RB) one or more changes of
E-, S-, X-bits and/or loss of synchronism information have been lost.
(maskable by RE in the channel specification)
Example
V.110/X.30 channel with
CS = 0 (required)
INV = 0
CRC = 0
TRV = 00 (600 bit/s)
FA = 0
MODE = 10 (V.110/X.30)
Motorola interface
Channel No. D
PEB 20320
Functional Description
User’s Manual 123 01.2000
Figure 70a
ITS08219
0000 0000
0000...
00000001
10 0 00111
MUNICH32 waits for synchronization after reset
110111 1001110110 E9
H
B3B4B6 B2 B1B5
01110110
0111 1111
111 1
1110
0111
1100111 1
0011
11001100
Reported as X
Reported as SA
Reported as SB
00
001
100 1111
0011
1001
111
111 1
1110
00100111
1011
111001
1000 000
00000001
Error in synchronization pattern
B5 B1B2B6 B4 B3
H
CA010011 10
No change of E, S, X Bits
1
11
0000
00 000
00 00
No change of E, S, X Bits
111000 D2
H
B3B4B6 B2 B1B5
Error in synchronization pattern
1111
0011
111 1
110
11111
1000 000
00000000
111 1
111 1
111 1
111 1111 1
111 1
111 1
111 1
11
111100
000
10
11
11
11 111 111
10
Reported as SA
01
B5 B1B2B6 B4 B3
H
FA011 111
Change of E, S, X Bits; but SA is still reported as ’1’
0
1
111
111
0
Error in synchronization pattern
00
000
1
111
111 1
0000 0000 0000 0000 0000 0000 0
000
00
00
00
000
00
00
00
000
PEB 20320
Functional Description
User’s Manual 124 01.2000
Figure 70b
ITS08220
Error in synchronization pattern
10 0 0
00000000 1
00111111
1000 0001
10000001
111110
1000 0001
11 111
11111 111 11111 111 11111 111 11111 111 11111 111 11111 111 11111 111 11111 111 11111 111
0000 0000
0000001
11 11
EDH
111
0111
1111
1100
111 1
111111 1 1 Error in synchronization pattern
No change of E, S, X Bits
Change of E, S, X Bits
H
FF
111
11110001 11110001 11110001 11110001 11110001 11110001 11110001 11110001
0000 0000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
FFH
H
C0
No error in synchronization pattern
Change of E, S, X Bits
Change of E, S, X Bits
PEB 20320
Functional Description
User’s Manual 125 01.2000
Figure 71
For Intel mode the data sections have the form:
Figure 72
ITD05040
00080000
E9 CA FA D2
031 C0FFFFED
20040000
31 0
8800202D
31 0
31 0
8800022D
st
1 Desc 2 Desc
nd
Loss of Synch.
8E5B002D
8E5B002D 8C00002D
8F57002D
8FFF002D
40042000 40040000
ITD05041
C0 FF FF ED
031
nd
of 1 Desc
st
31 0
E9CAFAD2
of 2 Desc
PEB 20320
Functional Description
User’s Manual 126 01.2000
2.5 Boundary Scan Unit
In MUNIC H32 a Te st Acc ess Por t (TAP) cont roller is impl ement ed. The e ssent ial par t of
the TAP is a finite state machine (16 states) controlling the different operational modes
of the boundary scan. Both, TAP controller and boundary scan, meet the requirements
given by the JTAG standard: IEEE Std. 1149.1. Figure 73 gives an overview.
Figure 73
Block Diagram of Test Access Port and Boundary Scan
Test handl ing is perfo rmed via the p ins JT EST0 (T CK), J TEST1 (TMS) , JTES T2 (TDI )
and JTEST3 (TDO). Test data at JTEST2 (TDI) are loaded with a 4-MHz clock signal
connected to JTEST0 (TCK). ‘1’ or ‘0’ on JTEST1 (TMS) causes a transition from one
controller state to an other; constant ‘1’ on JTEST1 (TMS) leads to normal operation of
the chip.
If no boun dar y scan te sting i s plan ned JT EST1 (TMS) a nd JTEST 2 (TDI) do not n eed to
be conne cted since pull-up transistors ensure high input levels in this case. Nevertheless
it woul d b e a g ood pra cti ce to put the unus ed inp uts to defined le vel s. In this case, if the
JTAG is not used:
JTEST1 = JTEST0 = ‘1’.
After sw itching on the de vice (VDD = 0 to 5 V) a powe r-on reset is generate d which forces
the TAP controller into test logic reset state.
Clock
Generation
CLOCK
Reset
Power ON
Reset
TAP Controller
-Finite State Machine
-Instruction Register (3 bits)
-Test Signal Generator
JTEST0 (TCK)
JTEST1 (TMS)
JTEST2 (TDI)
JTEST3 (TDO)
CLOCK
Test
Control
Data IN
Control Bus
6
ID Data OUT
SS Data OUT
BS Data IN
Identification Scan (32 Bits)
Boundary Scan (n Bits)
1
2
n
Pins
ITB03509
Enable
Data OUT
Test Access Port
PEB 20320
Functional Description
User’s Manual 127 01.2000
Table 6
Boundary Scan Sequence in PEB 20320
JTEST2 (TDI) →
Pin
No. Pin I/O Number of
Boundary Scan Cells Constant Value
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Reset
SCLK
TEST
AR
TDATA
TSP
TCLK
I/M
B16
Ready/DSACK
BERR
HLDA/BG
HLDAO/BGO
BGACK
HOLD/BR
ADS/AS
DS
WR/RW
BE3
BE2
D0
BE1
D1
BE0
D2
A2
D3
A3
D4
A4
D5
A5
D6
A6
D7
I
I
I
I
O
I
I
I
I
I
I
I
O
I/O
I/O
O
O
O
O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
1
1
1
1
2
1
1
1
1
1
1
1
2
3
3
2
2
2
2
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
0
1
1
0
00
0
0
0
0
0
0
0
00
001
010
00
01
00
00
01
100
00
000
00
000
00
000
00
000
00
000
00
000
00
000
PEB 20320
Functional Description
User’s Manual 128 01.2000
Table 6
Boundary Scan Sequence in PEB 20320 (cont’d)
JTEST2 (TDI) →
Pin I/O Number of
Boundary Scan Cells Constant Value
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
A7
D8
A8
D9
A9
D10
A10
D11
A11
D12
A12
D13
A13
D14
A14
D15
A15
D16
A16
D17
A17
D18
A18
D19
A19
D20
A20
D21
A21
D22
A22
D23
A23
D24
A24
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
I/O
O
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
3
2
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
000
00
PEB 20320
Functional Description
User’s Manual 129 01.2000
→ JTEST3 (TDO)
An input pin (I) uses one boundary scan cell (data in), an output pin (O) uses two cells
(data out, enable) and an I/O-pin (IO) uses three cells (data in, data out, enable).
Therefore the boundary scan of the MUNICH32 contains a total of n = 205 scan cells.
The right column of Table 6 gives the initialization values of the cells.
The desired test mode is selected by serially loading a 3-bit instruction code into the
instruction register via JTEST2 (TDI) (LSB first); see Table 3.
Table 6
Boundary Scan Sequence in PEB 20320 (cont’d)
JTEST2 (TDI) →
Pin I/O Number of
Boundary Scan Cells Constant Value
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
D25
A25
D26
A26
D27
A27
D28
A28/DP0
D29
A29/DP1
D30
A30/DP2
D31
A31/DP3
INT/INT
RCLK
RSP
RDATA
CI0
CI1
CI2
CI3
CI4
I/O
O
I/O
O
I/O
O
I/O
I/O
I/O
I/O
I/O
I/O
I/O
I/O
O
I
I
I
I
I
I
I
I
3
2
3
2
3
2
3
3
3
3
3
3
3
3
2
1
1
1
1
1
1
1
1
000
00
000
00
000
00
000
000
000
000
000
000
000
000
00
0
0
0
0
0
0
0
0
PEB 20320
Functional Description
User’s Manual 130 01.2000
EXTEST is u sed to ex am ine th e in terc on nec tio n o f the device s on the board. In th is tes t
mode at first all input pins capture the current level on the corresponding external
interconnection line, whereas all output pins are held at constant values (‘0’ or ‘1’,
according to Table 6). Then the content of the boundary scan is shifted to JTEST3
(TDO). At the same time the next scan vector is loaded from JTEST2 (TDI).
Subsequ ently all ou tput pi ns are updated accord ing to the new bou ndary s can con tent s
and all input pins again capture the current external level afterwards, and so on.
INTEST supports internal testing of the chip, i.e. the output pins capture the current level
on the cor resp ondin g in ternal l ine where as all i npu t pins a re held o n cons tant value s (‘0’
or ‘1’, accor ding to Table 6). The resulting boundary scan vector is shifted to JTEST3
(TDO). The next test vector is serially loaded via JTEST2 (TDI). Then all input pins are
updated for the following test cycle.
Note: In capture IR-state the code ‘001’ is automatically loaded into the instruction
register, i.e. if INTEST is wanted the shift IR-state does not need to be passed.
SAMPLE/PRELOAD is a test mode which provides a snap-shot of pin levels during
normal ope rati on.
IDCODE: A 32-bit identification register is serially read out via JTEST3 (TDO). It contains
the version number (4 bits), the device code (16 bits) and the manufacturer code
(11 bits). The LSB is fixed to ‘1’.
IDCODE for old versions: 0001 for version 2.1
0010 for version 2.2
0100 for version 3.2
Note: As in test logic reset state the code ‘011’ is automatically loaded into the instruction
register the ID code can easily be read out in shift DR state which is reached by
JTEST1 (TMS) = 0, 1, 0, 0.
BYPASS: A bit entering JTEST2 (TDI) is shifted to JTEST3 (TDO) after one JTEST0
(TCK) clock cycle.
Table 7
Boundary Scan Test Modes
Instruction (Bit 2 …0) Test Mode
000
001
010
011
111
others
EXTEST (external testing)
INTEST (internal testing)
SAMPLE/PRELOAD (snap-shot testing)
IDCODE (reading ID code)
BYPASS (bypass operati on)
handled like BYPASS
JTEST2 (TDI) →0 110 00 00 0000 0000 0101 0000 1000 001 1 → JTEST3 (TDO)
PEB 20320
Operational Descr iption
User’s Manual 131 01.2000
3 Operational Description
3.1 Reset State
Upon re se t MUNICH 32 i s s e t to it s in i tia l st ate . T he ac ti v e h i gh s ys t em res e t cl ea rs t he
internal logic and causes MUNICH32 to tristate all output lines. Channel processing is
deactiv ate d. Afte r rese t all buffe rs are emp ty an d no bu ffer s iz e of TB is allo cated to the
channels. The DMA controller state is set to the hold condition for all link lists. The
descriptor and data pointers remain at a random value.
The bits R O and TO are set to ‘1’ an d RA and TA are set to ‘0’ for all log ica l chan nels b y
reset. All time slots are connected to the logical channel 0 and the followin g configuration
is set:
Action Specification
LOC = LOOP = LOOPI = 0
PCM = T1/DS1 × 24-c ha nne l 1.536 Mbit /s (000 )
MFL = 0
Time Slot Assignmen t
fill/mask = 00H, i.e. all bits masked/set to ‘1’
RTI, TTI = 0
channel number = 00H
Channel Specification
MODE = 00, i.e. TMA
FA = 0
IFTF = 0
CRC = 0
INV = 0
TRV = 00,
RA = 0
TA = 0
TH = 0
RO = 1
TO = 1
PEB 20320
Operational Descr iption
User’s Manual 132 01.2000
Transmit De scri ptor
FNUM = 00H, i.e. shared flags in HDLC, only eight zero bits between sent frames for
TMB.
The E-, S-, X-bits are all set to zero internally by the reset. The receiver is set into the
ITF/IDL E state for a ll channel s, i.e. it assumes t hat on the line there a re ‘1’s as interframe
time-fill for HDLC.
3.2 Initialization Procedure
After reset M UNI CH3 2 remai ns in the ini tial sta te un til the m icr opro ce ss or ge nera tes an
action request. In the action specification the initialization sequence is defined. The
sequence can be split up into individual procedures of each channel or in one single
procedure to initialize all channels at the same time. For all procedures the time slot
assignment and the selected channel specifications are loaded into the CSR-RAM. To
preve n t mal fu n ct ion t h e in it ia li z at ion o f th e li n k l i st s and t h e al loc at i on o f t h e buf f er si ze
to the ch annels h as to be specif ied befor e the transm issi on ca n be st arted. The in terrupt
queue must be established as well. MUNICH32 assumes that time slot 0 starts on the
receive and transmit lines. They can be resynchronized by 2 rising edges of TSP and
RSP respec ti vel y. Th e firs t ris ing e dge o f TSP/RSP should n ot tak e pla ce wi thin t he first
1000 SCLK clock cycles after deassertion of the reset pin.
Before this resynchronization the host should neither remove RO = 1, TO = 1 nor set
LOOP or LOOPI to ‘1’ for any logical channel. During this time any incoming data is
ignored, the transmit data line tristated.
For each ac tion se rvice the devi ce firs t reads the control star t address in the cont rol and
configuration section which is located under a fixed address determined by the input
signals (CI(4:0)).
The v alues of C I(4:0 ) ca n be c hanged duri ng op erati on. T he val ues ar e us ed af ter t he
next falling edge of AR.
CI4 is the polarity of A31 …A22
CI3 is the polarity of A21 …A16
CI2 is the polarity of A15 …A4
CI1 is the polarity of A3
CI0 is the polarity of A2
A0, A1 = 0
for example CI(4:0) = 10101
ADDRESS = 1111.1111.1100.0000.1111.1111.1111.0100
PEB 20320
Operational Descr iption
User’s Manual 133 01.2000
Figure 74
Figure 75
CI-Pin Decoding
313029282726252423222120191817161514131211109876543210
CI4 CI3 CI2 CI1 CI0 00
CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl.
Start Addr. CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl.
Start Addr.
000000000000010000FFC00000
000010000000410001FFC00004
000100000000810010FFC00008
000110000000C10011FFC0000C
001000000FFF0 10100FFC0FFF0
001010000FFF4 10101FFC0FFF4
001100000FFF8 10110FFC0FFF8
001110000FFFC 10111FFC0FFFC
01000003F000011000FFFF 0000
01001003F000411001FFFF 0004
01010003F000811010FFFF 0008
01011003F000C11011FFFF 000C
01100003FFFF0 11100FFFF FFF0
01101003FFFF4 11101FFFF FFF4
01110003FFFF8 11110FFFF FFF8
01111003FFFFC 11111FFFF FFFC
PEB 20320
Detailed Register Description
User’s Manual 134 01.2000
4 Detailed Register Descripti on
4.1 Organization of the Shared Memory
Because the MUNICH32 reads only long words, all addresses of the link lists, interrupt
queue and the CCS must be a multiple of four; i.e. the two least significant bits of the
address must be ‘00’. Figure 76 depicts the organization of the shared memory for one
MUNICH32.
PEB 20320
Detailed Register Description
User’s Manual 135 01.2000
Figure 76
Organization of the Shared Memory
Receive
DATA
Channel 0
Interrupt
Circular
Queue
Control Start Address
Action Specification
Interrupt Queue Specification
Time Slot 0 Assignment
Channel 0 Specification
Time Slot 31 Assignment
Channel 31 Specification
Control and Configuration Section
Current Transmit Descriptor
Address Channel 31
Address Channel 0
Current Transmit Descriptor
Current Receive Descriptor
Address Channel 31
Current Receive Descriptor
Address Channel 0
CCBA
Last 8 Blocks
not used in
T1/DS1 Mode
Channel 0
Descriptor
Receive
Channel 0
DATA
Transmit
Channel 0
Descriptor
Transmit Transmit
Descriptor
Channel 0
Receive
Descriptor
Channel 0
ITD03508
PEB 20320
Detailed Register Description
User’s Manual 136 01.2000
4.2 Control and Configuration Section
4.2.1 Action Specification (Read Once After Each Action Request Pulse)
All actio ns are selected by se tting the correspon ding bits to ‘1’.
PCM:These three bits determine the PCM highway format.
000: T1/DS1 24-channel 1.536 Mbit/s
100: T1/DS1 24-channel 1.544 Mbit/s
101: CEPT 32-channel
110: 4.096-Mbit/s PCM format and even numbered time slots
111: 4.096-Mbit/s PCM format and odd numbered time slots
MFL: Maximum Fra me Length (u p to 8191 bytes); MUNICH32 monitors the frame length
of the incoming HDLC, TMB or TMR frames. If the maximum frame length is
exceeded an interrupt is generated and the current frame aborted. The length
check is active in all modes except tran sparent mode A and V.110/X .30. Therefore
in all other modes one has to write a reasonable value to MFL after reset. MFL is
the same for all log ic al cha nne ls .
Table 8
Buffer Size of the Control and Configuration Section
Control and Configuration Section Number of Long Words
Action specification 1
Interrupt queue specification 2
Time slot assignment 32
Channel specification 128
Current descriptor address 64
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PCM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IN IC0 0 Channel Numbe r IM RES LOC LOOP LOOPI IA 0 0
MFL
PEB 20320
Detailed Register Description
User’s Manual 137 01.2000
IN: Initialization procedure; setting this bit to one causes MUNICH32 to fetch all the
time slot assignments and the channel specification of the selected channel
(channel number). To avoid collision all time slots being reinitialized should be in
a deactivated mode, i.e. the receive and transmit channels must be switched off.
ICO: Initialize Channel Only; only the channel specification of the selected channel
(channel number) is read and reconfigured.
IM: Interrupt Mask; MUNICH32 suppresses the interrupt normally generated in order
to acknowledge the action request.
RES: RESET; a single initialization procedure is performed. The time slot assignment
and all channel specifications are written into the CSR. All time slots are
reinitialized.
Note 1: The bits IN, ICO, RES are mutually exclusive within one action specification.
They establish different ways of initializing, configuring and reconfiguring the
channels and time slots of the MUNICH32.
For test purposes four different loops can be switched at the serial interface with aid of
LOC, LOOP, LOOPI according to the following table
LOC LOOP LOOPI Interpretation
000no loop
100not allowed
0 0 1 complete internal loop
1 0 1 channelwise internal loop
0 1 0 complete external loop
1 1 0 channelwise external loop
011not allowed
111not allowed
The loops have the following functions:
–Complete extern al loop
The seria l data input is physicall y mirrored ba ck to the s erial data ou tput. The time and
strobe signals for receive and transmit direction have to be identical.
–Complete internal loop
The serial data outp ut is physi cally mirrore d back to the serial da ta inpu t. The data on
the external input line are ignored. The logical channels have to be programmed
identically. The time and strobe signals for receive and transmit direction have to be
identical.
PEB 20320
Detailed Register Description
User’s Manual 138 01.2000
–Channelwise external loop
One single logical channel is mirrored logically from serial data input to serial data
output. The other channels are not affected by this operation. The data rate for this
single logical channel has to be identical for receive and transmit direction.
–Channelwise internal loop
One single logical channel is mirrored logically from serial data output to serial data
input. The other channels are not affected by this operation. The data rate for this
single logical channel has to be the same for receive and transmit direction.
See Chapter 5.1 and Chapter 5.3.2 for a more detailed discussion of test loops.
All loops of the MUNICH32 V3.2 are under complete software control. Loops can be
closed and opened via software.
Handling of the MUNICH32 V3.2 loops:
Switch loops on:
RES = IN = ICO = ‘0’
LOC, LOOP, LOOPI for selected loop type
PCM, MFL, IM, IA don’t change the previous values
CHANN EL NUM BER in case of cha nne lwis e loops use the selecte d
channel num ber
in case o f complete l oops use ch annel numbe r of an
active channel.
Switch loops off:
RES = IN = ICO = ‘0’
LOC = ‘0’, LOOP = LOOPI = ‘1’
PCM, MFL, IM, IA don’t change the previous values
CHANNEL NUMBER use channel number used with the ‘switch loop on’.
IA: Interru pt Attention; a new inte rrupt queue is defined by the host. MUNICH3 2 reads
the interrupt queue specification and writes the interrupt information into the new
interrupt queue.
PEB 20320
Detailed Register Description
User’s Manual 139 01.2000
Figure 77
Action Specification
ITS08221
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5
PCM
IN
ICO
LOC
Channel
Number
0
43210
00
RES
IM
LOOP
LOOPI
IA
MFL
Maximum Frame Length
Maximum size of a received frame
in HDLC, TMB and TMR mode (up to 8192 bytes).
A received frame is aborted and an interrupt
is generated if the size of a received frame
exceeds the MFL value.
MFL applies to all channels.
PCM Highway Format
0 0 0
0 0 1
0 1 0
0 1 1
1 0 0
1 0 1
1 1 0
1 1 1
Not Allowed
T1/DS1 24 Time-Slots, 1.536 Mbit/s
Channel No.
Used in
conjunction
with IN
Initialize Channel Only
Only the channel spec.
(channel number) is
read and reconfigured.
Initialization Procedure
Read the complete time-slot
assignment and the channel
spec. of the specified channel
(channel number).
Interrupt Attention
A new interrupt queue
has been defined. Read
the interrupt queue
specification.
No Loop
Complete Internal Loop
Channelwise int. Loop
Channelwise ext. Loop
1 1 1
1 1 0
1 0 1
1 0 0
0 1 1
0 1 0
0 0 1
0 0 0
Loops
Complete Internal Loop
Read the complete time-slot assignment
Read all channel specifications
Reinitialize all time-slots
Reset
Do not generate the ARACK & ARF interrupt
Interrupt Mask
and ICO
of the selected channel
Not Allowed
Not Allowed
CEPT 32 Time-Slots, 2.048 Mbit/s
4.096 Mbit/s PCM Format, even Time-Slots
4.096 Mbit/s PCM Format, odd Time-Slots
Not Allowed
Not Allowed
Not Allowed
T1/DS1 24 Time-Slots, 1.544 Mbit/s
PEB 20320
Detailed Register Description
User’s Manual 140 01.2000
4.2.2 Interrupt Queue Specification
The interrupt queue is specified as a kind of block (queue), starting on a start address
(programmable) with a defined length (programmable). Both, the start address and the
queue length are programmable in the Interrupt Queue Specification of the Control and
Configuration Se ction.
Figure 78
The mini mum queue s ize is 16 lon g words; the max imum queue siz e is 4096 long words.
For each interrupt arising, the MUNICH32 writes the interrupt information into the
inter rupt queu e, will inc remen t the point er to the next addres s in this block autom atic ally
and will generate an interrupt pulse at each interrupt occasion. It is up to the processor
to read the interrupt informations out of the interrupt queue. If the MUNICH32 arrives at
the end of the in terrupt q ueue, it wi ll jump to the st art addr ess of th e interrupt block agai n
(cyclic queue) and completely overwrite the previous information.
Therefore the len gth of th e interru pt queu e shou ld be c alcul ated so , that th e MUNIC H32
will not overwrite information which was not yet read by the processor.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Interrupt Queue Address
0000000000000000
1514131211109876543210
Interrupt Queue Address
00000000 n
START ADDRESS
(Interrupt Queue
Address) length =
(n + 1) ×16 long words
where 0 ≤ n ≤ 255
overwrite
.
.
.
interrupt information long word 1
interrupt information long word 2
interrupt information long word 3
interrupt information long word (n+1)x16
PEB 20320
Detailed Register Description
User’s Manual 141 01.2000
4.2.3 In terrupt Information
The next table shows the bit assignments for the interrupt information long word.
When an interrupt occurs MUNICH32 se ts the INT bit and writes the interrupt information
and the channel number into the interrupt circular buffer. At the same time it generates
an interrupt pulse. The classes of error (for example host initiated interrupt or CRC error)
of a chann el in on e direc tion are treated i ndepen den tly of eac h other. If s evera l interru pt
events coincide they will be indicated to the host with one shared interrupt.
Bit assignment for interrupt queue
There are 3 classes of bits in the interrupt:
1. Bits present in each interrupt:
INT: this bit is always set to ‘1’
VN(3:1): these bits are ‘000’ for version 1.1
‘001’ for version 2.1
‘010’ for version 2.2
‘100’ for version 3.2
‘110’ for version 3.4
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
INT 0 Inter rupt Info rma tio n
1514131211109876543210
Interrupt Info rma t io n Channe l Nu mb er/Dire ct ion
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
INT 0 VN3 VN2 VN1 FRC E7 E6 E5 E4 E3 E2 E1 SB SA X
15 1413121110 9 876543210
ARACK ARF HI FI IFC SF ERR F O 0 0 RT Channel Number
PEB 20320
Detailed Register Description
User’s Manual 142 01.2000
2. Action request interrupts
ARACK: Action Request Acknowledge; MUNICH32 sets the ARACK bit to indicate
that an action request has been serviced.
ARF: Action Request Fail; MUNICH32 aborts an ACTION REQUEST, if the
required configuration ca nnot be performed . An action req uest fail can occur
either when the TB buffer is initialized incorrectly or a bus cycle error
(BERR = 0) is detected during a configuration access.
If ARACK or ARF is set, all bits except INT and VN(3:1) are set to 0.
Note: An action request is forbidden during the time a preceding action has not been
finished by an ARACK or ARF interr upt or a pulse at the reset pin.
3. Channel specific interrupts
These interrupts indicate specific events in the channel indicated by
‘Channel Number’ and receive or transmi t directi on indicate d by RT (RT = ‘1’: receive
direction; RT = ‘1’: transmit direction).
The interpretation of these interrupts depends on the specification of the channel in
which they occur.
The follow in g tab le shows w hich interrupts can occur in wh ic h mo de (u nus ed bits are
always 0).
HDLC
1 0FFF0 0 000000000
V.110/X.30
1 0FFFR R RRRRRRRRR
TMA
1 0FFF0 0 000000000
TMB/TMR
1 0FFF0 0 000000000
HDLC
G GTRTRRRTRTR00 XXXXXX
V.110/X.30
G GTR000 TRTR00 XXXXXX
TMA
G GTRT00 TRTR00 XXXXXX
TMB/TMR
G GTRTR00 TRTR00 XXXXXX
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
INT 0 VN3 VN2 VN1 FRC E7 E6 E5 E4 E3 E2 E1 SB SA X
15 1413121110 9 8765 43210
ARACK ARF HI FI IFC SF ERR FO 0 0 RT Channel Number
PEB 20320
Detailed Register Description
User’s Manual 143 01.2000
Where ‘1’means that the bit is always ‘1’ for this mode
‘0’means that the bit is always ‘0’ for this mode
‘F’means the bit is fixed by the version number
‘R’means a bit that can only be set in the receive direction, i.e. may only
be ‘1’ if RT is ‘1’
‘T’means a bit that can only occur in transmit direction, i.e. may only
be ‘1’ if RT is ‘0’
‘TR’means a bit that can occur in receive or transmit direction
‘G’means a bit of an activation request interrupt which cannot be
‘G’ in a channel specific interrupt
‘X’means a bit fixed by the channel and direction (receive, transmit)
of the event it belongs to.
The meaning of the interrupt bits depend on the mode. We therefore will discuss them
bit for bit and indicate the different meanings in the different modes.
FRC: (V.110/X.30 mode, receive direction only)
Change of the framing (E, S, X) bits of the V.110/X.30 frame detected.
This interrupt is generated whenever a change in the E-, S-, X-bits is
detected, but at most one time within one frame of 10 octets, even if the re
is more than one change wi thin the f rame. After detecting a recei ve abort
channel command for one 10-octet frame FRC is also issued.
Ex, Sx, X: (V.110/X.30 mode, receive direction only, only in conjunction with FRC)
The value of the bits Ex, Sx, X in the received V.110/X.30 frame. If a
value changes, e.g. 2 times within the same frame only the final change
is reported.
If the change was caused by a receive abort channel command all bits
are 0.
HI: (all modes, all direction)
Host initiated Interrupt; this bit is set when the MUNICH32 detects the
HI bit in the receive or transmit descriptor and branches to the next
descriptor, or starts polling the hold bit if set.
FI: 1.1 HDLC, TMB, TMR Receive Direction:
FI = 1 indicates, that a frame has been received completely or was
stopped by a receive abort channel command or fast receive abort or a
HOLD in a receive descriptor. It is set when the MUNICH32 branches
from the last descriptor belonging to the frame to the first descriptor of a
new frame. It is also set when the descriptor in which the frame finished
contained a hold bit, the interrupt is then issued when the MUNICH32
starts polling the hold bit.
1.2 HDLC, TMB, TMR, TMA Transmit Direction:
issued if the FE bit is detected in the transmit descriptor. It is set when
the MUNICH32 branches to the next transmit descriptor, belonging to a
PEB 20320
Detailed Register Description
User’s Manual 144 01.2000
new f ram e, o r w h en it s t art s po l li ng t h e h old bi t i f set i n co nju nc ti o n wit h
the FE bit; ERR and FI are set if a transmit descriptor contains a
HOLD bit no FE bit
IFC: (HDLC mode, receive direction only)
Idle/Flag Change; an interrupt is generated in HDLC if the device
changes the interfra me time-fill (ITF ) stat e. After reset the device is in the
ITF idle state. It changes to the ITF flag state if it receives 2 consecutive
flags with or witho ut sh ared zeroes. It changes bac k to the ITF idl e sta te
upon rece ption of 15 co ntiguo us ‘1’-bi ts or when a recei ve abort cha nnel
command is active during 15 received bits.
SF: (HDLC mode, receive direction only, always in conjunction with FI)
Short frame detected
A frame with ≤16 bits between start flag and end flag or end abort flag
for CRC16
≤32 bits between start flag and end flag or end abort flag
for CRC32
has been d etecte d. The s equen ces 7E 7FH and 7E FEH and 7E FFH are
also short frames.
SF is always in conjunction with ERR except for the frames
7E00 007EH for CRC16
7E00 0000 007EH for CRC32
ERR: always in conjunction with FI = 1
1.1 HDLC mode Receive Direction
One of the following receive errors occurred
– FCS of the frame was incorrect
– the bit length of the frame was not divisible by 8
– the byte length exceeded MFL
– the frame was stopped by 7FH
– the frame could only be partly stored due to
internal buffer overflow of RB
– the frame was ended by a receive abort channel command
– the frame could not be transferred to the shared memory completely
because of a hold bit set in a receive descriptor not providing enough
bytes for the frame.
– the frame was aborted by a fast receive abort channel command
A more detailed error analysis can be done by the status information in
the receive descriptor.
1.2 HDLC mode Transmit Direction
one of the following transmit errors occurred:
– the last descriptor had HOLD = 1 and FE = 0
– the last descriptor had NO = 0 and FE = 0
PEB 20320
Detailed Register Description
User’s Manual 145 01.2000
2.1 V.110/X.30 mode Receive Direction
one of the following receive errors occurred:
– data could only partly stored due to internal buffer overflow of RB
– 3 consecutive frames had an error in the synchronization pattern
(loss of synchronism)
– a fast receive abort channel command was issued
– the data could not be transferred to the shared memory completely
because of a hold bit set in a receive descriptor not providing enough
bytes for the data
– a receive abort channel command was active for at least
3 consecutive frames
A more detailed error analysis can be done by the status information in
the receive descriptor.
2.2 V.110/X.30 mode Transmit Direction
one of the following transmit errors occurred
– the last descriptor had a HOLD = 1 or FE = 1
– the last descriptor had FE = 0 and NO = 0
3.1 TMA mode Receive Direction
one of the following errors occurred
– the data could not be transferred to the shared memory completely
because of a hold bit set in a receive descriptor not providing enough
bytes for the data
– a fast receive abort channel command was issued
3.2 TMA mode Transmit Direction
see Chapter 1.2
4.1 TMB/TMR mode Receive Direction
always in conjunction with FI = 1
one of the following receive errors occurred
– the bit length of the frame was not divisible by 8
– the frame could only be partly stored due to
internal buf fer ove rflo w of RB
– the frame could not be transferred to the shared memory completely
because of a hold bit set in a receive descriptor not providing enough
bytes for the frame
– the frame was aborted by a fast receive abort channel command
A more detailed error analysis can be done by the status information in
the receive descriptor.
4.2 TMB/TMR mode Transmit Direction
see 1.2
FO: 1.1 HDLC, TMB, TMR Receive Direction
The MUNICH32 has discarded one or more whole frames or short
PEB 20320
Detailed Register Description
User’s Manual 146 01.2000
frames or change of interframe time-fil l informations due to inaccessibility
of the internal buffer RB.
1.2 HDLC, TMB, TMR Transmit Direction
The MUNICH32 is unable to access the shared memory in time or has
detected a bus cycle error (BERR = 0) during a read access on the
transmit data section. The current erroneous frame is aborted with a ‘0’
and 14 ‘1’ for HDLC, with 00 for TMB and 0000 for TMR; afterwards
interframe time fill is sent until the MUNICH32 can access again the
shared memory. The MUNICH32 will read the transmit data from the
location which should b e accessed bef ore the Tx-FO or BE RR happene d
and transmit the rest of the erroneous frame.
2.1 V.110/X.30 Receive Direction
The MUNICH32 has discarded a loss of synchronism information or a
change of a E-, S-, X-bits information due to inac cessib ility of the internal
buffer RB.
2.2 V.110/X.30 Transmit Direction
The MUNICH32 is unable to access the shared memory in time or has
detected a bus cycle error (BERR = 0) during a read access on the
transmit data section. It generates 3 10-octet frames with framing errors
and restarts with the next error-free transmit data.
3.1 TMA Receive Dire ction
The MUNICH32 has discarded data due to inaccessibility of the internal
buffer RB.
3.2 see Chapter 1.2
The f oll owin g ta ble shows whic h in ter rupt bit s are mask ed b y wh ich bits i n th e ch ann el
specification.
Receive CH
Transmit –
Receive FIR IFC SFE RE RE
Transmit FIT ––TE TE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
INT ∅VN3 VN2 VN1 FRC E7 E6 E5 E4 E3 E2 E1 SB SA X
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ARACK ARF HI FI IFC SF ERR FO 0 0 RT Channel Number
PEB 20320
Detailed Register Description
User’s Manual 147 01.2000
General
IM IM
Figure 79
Interrupt Information
ITS08222
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4
INT
0 VN(3...1)
FRC
E7
E6
E5
E4
E3
E2
E1
SB
SA
X
ARACK
ARF
HI
FI
IFC
SF
ERR
F0
00
RT
Channel
Number
Framing Bits Changed
V.110/X30 mode
received E, S, X Bits changed
Action Request Acknowledge
Action request has been
completed successfully.
Action Request Failed
Action request could not be
Host Initiated Interrupt
HI Bit in the Rcv./Xmt. descriptor was set
End of receive or transmit frame indication
Frame Indication Interframe Timefill Change
HDLC receiver detected change in ITF state
Short Frame
(empty HDLC frame or incorrect HDLC frame,
HDLC mode, in conjunction with FI
Protocol Error
e.g. CRC error, frame aborted,
loss of sync. MFL exceeded
Internal buffer overflow/underflow
Overflow/Underflow
Internal buffer not available
Direction
0 Transmit Interrupt
1 Receive Interrupt
Channel Number
Identifies the channel
where the interrupt
occured.
3210
Silicon Version Number
0 0 0 V1.1
V2.10 0 1
0 1 0 V2.2
Valid Interrupt Entry
MUNICH32 sets this Bit with every entry
to the interrupt circular queue
Software should dear this Bit after reading
V3.21 0 0
completed successfully.
nothing stored in memory)
PEB 20320
Detailed Register Description
User’s Manual 148 01.2000
4.2.4 Time Slot Assignment
(Read only once after each action request pulse with an action specification with set IN
or RES bit)
The time slot as signm ent prov ides the cros s refere nce bet ween the 32 (24) time sl ots of
the PCM highway and the data channels (up to a maximum number of 32). The data
channels can be composed of different receive and transmit time slots, which have
individual bit rates. With the concept of subchanneling, MUNICH32 can realize flexible
transmission from 8 kbit/s up to 2.048 M bit/s per channel.
Fill/Ma sk Code: For bit rate adapti on the fill/mask cod e determi nes the number of bit s
and the position of these bits within the time slot. For all modes
except TMA the bits selected by Fill/Mask = 1 in the slots of a channel
are concatenated, those with Fill/Mask = 0 are ignored/tristated in
receive/transmit direction. For TMA the bits with Fill/Mask = 0 are
received as ‘1’-bits, in transmit direction these bits are overwritten
with ‘Z’ (see Chapter 2.4 for more details).
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 TTI Transmit Channel
Number Transmit Fill Mask time slot 0
0 0 TTI Transmit Channel
Number Transmit Fill Mask time slot 1
0 0 TTI Transmit Channel
Number Transm it Fill Mask time slot 31
1514131211109876543210
0 0 RTI Receive Channel
Number Receive Fill Mask time slot 0
0 0 RTI Receive Channel
Number Receive Fill Mask time slot 1
0 0 RTI Receive Channel
Number Receive Fill Mask time slot 31
PEB 20320
Detailed Register Description
User’s Manual 149 01.2000
Channel Number: The channel number identifies the data channel. Its transmission
mode is described in the respective channel specification.
TTI: Trans mit Tim e slot In hibit; se tting thi s bit to ‘1’ causes MUNICH32 to
tristate the transmit time slot. The data is not destroyed but sent in
the next not tristated time slot allocated to this channel.
RTI: Receive time Slot Inhibit; setting this bit to ‘1’ causes MUNICH32 to
ignore the received data in the time slot. The channel is not
processed in this time slot.
4.2.5 Channel Specification
(Read o nly on ce afte r eac h a ct iva tion request p uls e w i th a n ac tio n s pec if ic atio n w it h s et
IN, RES or IC O bit; R ES: the chan nel sp ecifi cation s of al l chan nels; IN, IC0: the c hanne l
specification of the channel indicated in the action specification)
Interrupt Mask:
These bits mask the bits in the interrupt information long word according to the table at
the end of Chapter 4.2.3 (interrupt information).
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Inter r upt Ma sk NITB S RI TI TO TA TH RO RA
FRDA
FTDA
00000000 0 0000000
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TFLAG TFLAG
/NSF TFLAG
/CS INV CR
CTRV FA Mode IFT
F
FRDA
FTDA
000000 0 0 0 0 ITBS
76543210
–SFE IFC CH TE RE FIR FIT
PEB 20320
Detailed Register Description
User’s Manual 150 01.2000
If an event leads to an interrupt with several bits set (e.g. FI and ERR) masking only a
proper subset of them (e.g. ERR) will lead to an interrupt with the nonmasked bits set
(e.g. FI). If all bits of an event are masked, the interrupt is suppressed. The interrupt
mask is therefore bit specific and not event specific.
NITBS: New ITBS valu e; if this bit is set the indiv idual transm it buffer si ze ITBS is valid
and a n ew b uffe r fi eld of TB is as si gned to the channel. In this proc es s firs t th e
occupied buffer locations of the channel are released and then according to
ITBS a new buffer area is allocated. If there is not enough buffer size in TB
(occupi ed by o ther chan nels) the process will be aborted and a n action req uest
failure interrupt is generated. After aborting no buffer size is allocated to the
channel . For preve nting ac tion requ est failure enough bu ffer loca tions must be
available. This can be done by reducing the buffer size of the other channels.
To avoid transmission errors all channels to be newly configured must be
deactivated before processing.
Note: ITBS has to be set to ‘0’ if NITBS = ‘0’.
NITBS should be set to ‘0’ in con juncti on wit h a trans mit abort cha nn el comm and.
The bits RI, TI, TO , TA, TH, RO, RA are the so c alled ch annel co mmand b its. They al low
the channel to be initialized, aborted or reconfigured at the serial side as well as at the
µP side.
These bits can be decomposed in 3 independent command groups:
RI, RO, RA form the receive command group
TO, TI, TA the first transmit command group
and TH is the second transmit command group.
We will discuss these bits according to the groups.
1. Receive command group (6 commands)
–receive clear
RI = 0 , RO = 0, RA = 0 (clears a previo us recei ve abort or receive off cond ition, aff ects
only the serial interface)
The effect of this command depends on the previous history of the channel
•if the channel was never initialized by a receive initialization command it has no
effect
•if it was initialized previously it clears a receive off or receive abort condition set by
a previous channel command
•if no receive off or receive abort condition is set it has no effect.
–fast receive abort
RI = 0 , RO = 0, RA = 1 (clears a previo us recei ve abort or receive off cond ition, aff ects
only the DMA interface)
This abort is performed in the DMA cont roller and does not interfere with the receptio n
on the serial interface and the transfer of the data into the receive buffer. If this abort
is detec ted the curre nt receive d escriptor is su spended w ith an abort s tatus (RA bit s et
PEB 20320
Detailed Register Description
User’s Manual 151 01.2000
to ‘1’) followed by a branching to the new descriptor (FRDA) defined in the channel
specification of the CCS.
For HDLC, TMB, TMR the rest of a frame which was only partially transferred before
suspension of the receive descriptor is aborted, the new descriptor is related to the
next frame. An interrupt with FI, ERR is issued. For V.110/X.30 and TMA data bits
might get lost. An interrupt with ERR is issued.
–receive off
RI = 0, RO = 1, RA = 0 (clears a previous receive abort condition, sets off condition,
affects only the serial interface)
This channel command sets the receiver into the receive off condition. The receive
channel is disabled completely at the serial interface, i.e. the receive deformatter RD
is reset and the receive buffer RB is not accessed for this channel. A currently
processed frame (HDLC, TMB, TMR mode) is not properly finished with any status
information. The data stored in the RB at that time is still transferred to the shared
memory.
After the receive off condition is cleared by another channel command:
•in HDLC, TMB, TM R (V.110/X.30, TM A) mode the device wa its for a new frame (10-
octet frame, nothing) to begin and then starts filling RB again. If the receive off
comman d lea d to a n imp roper fi nishi ng of a fram e (dat a, data ), the new frame (data,
data) is concatenated with the finished one. To avoid this problem there are two
suggestions:
a) issue a receive abort channel command and wait for 32 (240, 8) bits for this
channel to be processed before issuing the receive off command.
b) wait in the receive off condition until the RB is emptied for this channel (i.e. for at
most 8 PCM frames if the MUNICH32 has sufficient access to the shared
memory) and leave the rec ei ve of f con dition by a recei ve initi al iza tion comman d.
The receive off channel command is ignored in case of any kind of loop.
–receive abort
RI = 0, RO = 1, RA = 1 (clears a previous receive off condition, sets a receive abort
condition, affects only the serial interface)
This receive channel command sets the receiver into the receive abort condition. In
this condition it receives (instead of the normally received bits)
logical ‘1’ bits for HDLC
logical ‘0’ bits for V.110/X.30, TMB, TMR
logical ‘0’ bits for unmasked bits in TMA mode
logical ‘1’ bits for masked bits in TMA mode
irrespective of the INV bit.
This leads to
•For HDLC: a currently processed frame is aborted after ≤7 received bits for this
channel, leading to a RA set in the status of the frame and an interrupt with set FI
and ERR bit s only or to an in terrupt wit h set SF, FI and ERR b its. If the rec eiver wa s
PEB 20320
Detailed Register Description
User’s Manual 152 01.2000
in the f lag interf rame tim e-fill sta te it will lead to an inte rrupt with s et IFC bit after ≤15
received bits.
•For V.110/X.30: if the receiver was in the synchronized frame state it will go to the
unsynchronized state after ≤ 240 bits and issue a LOSS bit in the status of the
current receive d es cri pto r. It w il l als o is su e a n interrupt wi th se t ER R bit and (unl es s
all E-, S-, X-bits were 0 previously) issue one or two interrupts with FRC set and
having all E-, S-, X-bits at 0 in the last one.
•For TMB: a currently processed frame is aborted after ≤15 received bits for this
channel, leading to an interrupt with FI set but ERR on 0, the status of this frame is
always 00H.
•For TMR: a currently processed frame is aborted after ≤31 received bits for this
channel, leading to an interrupt with FI set but ERR on 0, the status of this frame is
always 00H.
•For TMA: the device receives the inverse of the fill/mask bits programmed for this
channels.
Note 1: It is advisabl e to clear the receiv e abort conditio n via a receive off co mmand for
V.110/X.30 mode, the TMB and the TMR mode.
2. After issuing a receive abort channel command it is advisable to stay in this
conditi on during at l east 16, 240 , 16, 32, 8 bits of the channel fo r HDLC, V.110/
X.30, TMB, TMR, TMA respectively.
–receive jump
RI = 1 , RO = 0, RA = 0 (clears a previo us recei ve abort or receive off cond ition, aff ects
only the DMA interface)
During normal operation branching to a new descriptor (FRDA) is possible without
interrupting the current descriptor and aborting the received frame (HDLC, TMB,
TMR) or received data (V.110/X.30, TMA).
The DMA cont roller will proceed finishing the current receive descriptor as usual either
with a frame end cond ition or with the correspo nding da ta buffer compl etely fil led and
afterwards branch to the new descriptor specified by FRDA. Thus a received frame
may be splitted on ‘old’ and ‘new’ descriptors.
–receive initialization
RI = 1, RO = 0, RA = 1 (clears a previo us recei ve abort or receive off cond ition, aff ects
the DMA and serial interface)
Before the MUNICH32 has got a receive initialization command it will not receive
anything properly in a channel. This command should therefore be the first channel
command after a pulse at the reset pin for a channel to be used. FRDA is then the
address of the starting point of the receive descriptor chaining list.
If the command is issued during normal operation it only affects the DMA interface.
The curre nt receiv e descrip tor is s uspended without writing the sec ond long w ord with
the status, no interrupt is generated. For HDLC, TMB, TMR the rest of a frame which
was only partially transferred before the suspension of the receive descriptor is
PEB 20320
Detailed Register Description
User’s Manual 153 01.2000
aborted, the new descriptor (FRDA) is related to the next frame.
For V.110/X.30 and TMA data bits might get lost.
General Notes to Receive Commands:
1. After a pulse at the reset pin a ch annel having a t ime slot with RTI = 0 should be issued
receive off commands until it is supposed to be used.
2. When it is supposed to be used it should be issued a receive initialize command
before using any other receive channel command.
3. To shut down a channel in receive direction one should first set it into the receive abort
condition for the time specified there and then set it into the receive off condition.
4. Before chang ing the MODE, CRC, CS, TRV, INV, TFLAG bits of a channel or its RTI
or time slot assignment or its fill/mask bits it should have been shut down. The bits
should be changed while issuing the receive off command.
5. To revive a channel after it has been shut down one should use the receive
initialization command.
6. To switch to a new starting point of a receive descriptor chain one should preferably
use the receive jump command, only exceptionally the fast receive abort command
and never the receive initialize command.
7. To issue channel commands not affecting the receive side one should issue
–a rece iv e clear comman d if n ei ther a receive o ff no r a re cei ve abo rt condition i s s et
–a receive off command if a receive off condition is set
–a receive abort command if a receive abort condition is set.
8. Combinations of the bits RI, RO, RA not in this description are reserved and are not
allowed to be used.
2. First Transmit Command Group
–transmit clear
TI = 0, TO = 0, TA = 0 (clears a previous transm it abort or transmit off con dition, affects
only the serial interface)
•if the channel was never initialized by a transmit initialization command it has no
effect
•if it was initia lized previous ly it c lears a transm it off or tra nsmi t abort c onditi on set by
a previous ch annel comma nd
•if no transmit off or transmit abort condition is set it has no effect
–fast transmit abort
TI = 0, TO = 0, TA = 1 (clears a previous transm it abort or transmit off con dition, affects
only the DMA interfac e)
This abort is performed in the DMA controller and does not interfere with the current
transmission on the serial interface and the transfer between the TF and TB. If this
abort is detected the current descriptor is suspended an d the frame or data transferre d
to the TB is aborted. The next frame beginning in the transmit descriptor (FTDA)
defined in the channel specification of the CCS will be started immediately.
PEB 20320
Detailed Register Description
User’s Manual 154 01.2000
For HDLC, TMB, TMR the first part of the frame of the suspended descriptor is sent
and append by 011 1111 1111 111 for HDLC
at least 00Hfor TMB
at least 00 00Hfor TMR
Afterwards the next frame is started.
For V.110/X.30 three 10-octet frames with errors in the synchronization pattern are
sent after the data of the suspended descriptor, afterward the next data are sent in
correct frames.
For TMA a TFLAG (FA = 1) or FFH (FA = 0) is sent in at least one time slot after the
data of the suspended descriptor, afterwards the next data are sent.
–transmit off
TI = 0, TO = 1, TA = 0 (clears a previous transmit abort condition, sets a transmit off
condition, effects only the serial interface)
The transmit channel is disabled immediately, i.e. the transmit formatter is reset and
the trans mit buffe r is not accessed for this c hannel. The output time sl ots are t ristated.
Upon leaving the transmit off mode the transmit link list must be initialized by a
transmit reinitialize command. Otherwise the transmission will be started with the
remaining data still stored in TB and continue with the old link list. If a loop condition
is set the transmit off does not reset the transmit formatter, it only tristates the serial
output line.
After the transmit off condition is cleared by the transmit initialize command.
• In HDLC, TMB, TMR, V.110/X.30 the device starts with the interframe time-fill
7E for HDLC and IFTF = 0
FF for HDLC and IFTF = 1
00 for TMB, TMR, V.110/X.30
and then with the frame in the de scriptor at FTDA. For V.110/X.30 this descriptor must
have the V.110-bit set and point to the E-, S-, X-bits, the data are then at the next
transmit des cr iptor.
• In TMA mode the device starts with the interframe time-fill
TFLAG for FA = 1
FFHfor FA = 0
and then with the data in the descriptor at the FTDA.
PEB 20320
Detailed Register Description
User’s Manual 155 01.2000
–transmit abort
TI = 0, TO = 1, TA = 1 (clears receive off condition, sets transmit abort condition,
affects only the serial interface)
This abort is performed in the transmit formatter at the serial interface. The currently
transmitted frame is aborted
by 011 1111 1111 1111 for HDLC
00Hfor TMB
0000Hfor TMR
3 frames with erroneous synchronization pattern for V.110/X.30
TFLAG for TMA, FA = 1
FF for TMA, FA = 0.
Afterwards or – if no frame is currently sent directly inter frame time fill:
7E for HDLC and IFTF = 0
FF for HDLC and IFTF = 1
00 for TMB, TMR, V.110/X.30
TFLAG for TMA, FA = 1
FF for TMA, FA = 0
is sent.
During tran smit abort the TF does not ac ce ss the tra ns mi t buff er. The han dli ng of the
link list is not affected b y the transmit abort, i .e. the device k eeps the TB full. Wh en the
transmit abo rt is w it hdra w n th e t r ans mi t fo rma tter continues th e transmiss io n w i th th e
data stored in TB. In the case of HDLC or TMB or TMR mode the remaining data of
the aborted HDLC or TMB frame is sent as a new independent frame. To avoid this
problem the link list must b e reiniti alize d by a tran smit initi aliza tion c omma nd tog ether
with the revoking of the transmission abort.
Another proper use of the transmit abort command consists in setting the last
descript or of the last fram e to be transmitted with HOLD = 1 and waiting fo r the devic e
to poll the HOLD bit (ITBS + 2) times where ITBS is the number of long words
assigne d to this channel currently. Afte rwards TB is empty and the tran smit abort then
issued does not abort a currently sent frame. The same procedure can also be used
for the transmit off comma nd .
–transmit jump
TI = 1, TO = 0, TA = 0 (clears a transmit off and transmit abort condition, affects only
the DMA interface)
This bit is set only duri ng normal operatio n. Then MUNIC H32 branches to the transmit
descriptor (FTDA) specified in the CCS after finishing the current transmit descriptor
without interrupting or aborting the transmitted frame.
The DMA contro ller w ill proc eed fin ishing the current tra nsmit des cripto r as usual an d
afterwards branch to the new descriptor specified by FTDA. If the current descriptor
does not inc lude a frame end (FE = 0) (HDLC, TM B, TMR) the DMA control ler will link
the following data section(s) of the ‘new’ descriptor chain to the opened frame. This
may generate unex pected f rames.
PEB 20320
Detailed Register Description
User’s Manual 156 01.2000
–transmit initializ ation
TI = 1, TO = 0, TA = 1 (clears a previous transmit abort condition, affects the DMA
interface and the serial interface)
Before the MUNICH32 has got a transmit initialization command it will not transmit
anything properly in th e c ha nne l. T his c omm an d s ho uld therefore b e th e fi rst cha nnel
command after a pulse at the reset pin for a channel to be used.
FTDA is then the address of the starting point of the transmit descriptor for chaining
list. In this cas e the transm it initialize com mand should be acc ompanied by the NITBS
bit set and a reas onable value for ITBS (0 < ITBS < 64) .
If the command is issued during normal operation it only affects the DMA. The
MUNICH32 stops processing of the current link list and branches to the transmit
descriptor at the FTDA address. The data stored in the TB are discarded and the TB
is filled with the data of the new descriptor.
3. Second Transmit Command Group
–Transmit HOLD
TH; setting this bit causes the device to finish transmission of the current frame
(HDLC, TMB, TMR mode) the current data (TMA -mode) or leads to an abort with
3frames with ‘0’-bits (V.110/X.30-mode). Afterwards
for HDLC mode and IFTF = 1 FFH fill characters
HDLC mode and IFTF = 0 7EH fill characters
V.110/X.30-mode 00H fill characters
TMA mode and FA = 1 TFLAG fill ch arac ters
TMA mode and FA = 0 FFH fill characters
TMB/TMR 00H fill characters
are sent until TH is withdrawn by a further action specification affecting the channel
specification of this channel.
Afterwards no further access to the TB from TF is done, therefore no further data are
fetched from the shared memory and the polling of a possible hold bit in the transmit
descriptor stops.
To send necessary frames/data before the transmit hold is active one should use the
proper procedure described under the transmit abort command.
General Notes to Transmit Commands:
1. After a pulse at the reset pin a channel having a time slot with TTI = 0 should be
issued transmit off commands and TH = 1 until it is supposed to be used.
2. When it is s upposed t o be used i t should b e issued a transmi t initiali zatio n command
and TH = 0 before using any other transmit channel commands (together with
NITBS = 1, ITBS ≠0).
3. To shut down a channel in transmit direction one should first set it into the transmit
abort condition or use the TH bit with the proper procedure. One should leave it in
PEB 20320
Detailed Register Description
User’s Manual 157 01.2000
that condition for 32, 240, 32, 32, 8 bits for HDLC, V.110/X.30,TMB, TMR, TMA
respectively and then set it into the transmit off condition.
4. Before changing the MODE, CRC, CS, TRV, INV, TFLAG bits or TTI or time slot
assignment or the fill/mask bits or the ITBS the channel should be shut down. The
bits should be changed while issuing the transmit off command.
5. To revive a channel after it has been shut down one should use the transmit
initialization command.
6. For V.110/X.30-mode the firs t descriptor after reviving from shut down or init ialization
after reset must have the V.110-bit set and contain the E-, S-, X-bits.
7. To switch to a new start ing point o f a transm it descri ptor chain one shoul d preferabl y
use the tran smit jump co mmand, only exceptional ly the fast trans mit abort comm and
and never the transmit initialize command.
8. To issue channel commands not affecting the transmit side one should issue
–TH with the last set value
–a transmit clear command if neither a transmit off nor a
transmit abort condition is set
–a transmit off if a transmit off condition is set
–a transmit abort if a transmit abort condition is set.
9. Bit combinations in the first transmit command group not described are reserved.
10. Se t NITBS = 1 pr efera bly in co njunc tion wi th a tra nsmit initial ize and transm it clea r
command if TB is to be newly configured, otherwise set NITBS = 0.
TFLAG: Transparent mode Flag; these bits are only used in the transparent mode A
and constitute the fill code for flag stuffing and for flag filtering. These bits
must be set to ‘0’ if subchanneling is used in transparent mode A. Bit No. 15
is the first bit of the flag to be received/transmitted.
NSF: No Short Frame suppression; NSF = 1 is only allowed in combination with
HDLC mode and CS = 1.
In this mode the MUNICH32 transfers all data to the shared memory even if
only one byte (or more) per ‘frame’ is received. No short frame interrupt and
no short frame status bit will be generated in this case.
Note:CRC is still calculated and checked and e.g. a frame of 1 or 2 byte length
(in CRC16 mode) will always cause an FI + ERR interrupt.
PEB 20320
Detailed Register Description
User’s Manual 158 01.2000
Receive Fram e Exam pl es :
a) 0x7E, data byte, 0x7E
− data byte copied to shared memory + frame end
− status SF-bit set
− no SF indication interrupt generated
− FI indication interrupt generated
− ERR interrupt generated due to wrong CRC’
b) 0x7E, data byte = 0xFC (or 0xFD o r 0x7F), 0x7E
− no data byte copied to shared memory
− SF and FI interrupt generated
CS: CRC Select; only used in HDLC mode. Setting this bit to ‘1’ causes the
MUNICH32 to transfer the CRC bits to the data section in the shared memory.
In receive direction the CRC check is carried out whereas in t ransmit direction
the CRC generation is suppressed, see Chapter 2.4 for more details.
INV: Inversion; If this bit is set, all data of the channel transmitted or received by
the MUNICH32 is inve rted.
CRC: Cyclic Redundancy Check; in HDLC mode this bit determines the
CRC g enerator polynomial: When the CRC bit is set to ‘1’ the 32 -bit CRC is
performed, otherwise the 16-bit CRC; for TMB/TMR mode this bit
distinguishes:
TMB: CRC = ‘0’
TMR: CRC = ‘1’
for all other modes this bit has to be set to ‘0’.
PEB 20320
Detailed Register Description
User’s Manual 159 01.2000
TRV: Transmission Rate of V.110/X.30. These signals determine the number of
repeated D-bits in a V.110/X.30 frame.
Note: In the other modes these bits must be set to ‘00’.
FA: Flag Adjustment selected (in HDLC mode) or flag filtering (selected in
transparen t mode A on ly i f all fill/ma sk bits of the corre spond ing sl ots are ‘1’).
In all other modes this bit must be set to ‘0’. If fl ag adj ustme nt is sel ected in
HDLC mode the numbe r of interfram e time-fill c haracters is FNUM mi nus one
eighth of the nu mber of zero insert ions in the frame proc eeding the interfram e
time-fill and belonging to the same transmit descriptor as FNUM.
If flag filtering is selected and fills a physical time slot in transparent mode A
the flag sp ecified in TFL AG is recogni zed and extrac ted from the dat a stream.
In transmit direction the flag TFLAG is sent in all exception conditions, i.e.
abort, idle s tate etc.; if flag fi ltering is not se lected ‘1’-bits are sent in this case.
Flag filtering is only allowed if all fill/mask codes are set to ‘1’, i.e.
subchanneling is not allowed.
If flag filtering is not selected the bits in TFLAG have to be set to 0 for TMA.
MODE: Defines the transmission mode:
11: HDLC mode
10: V.110/X.30 mode
00: Transpar ent mode A
01: Transpar ent mode B or transparent mode R .
IFTF: Interframe Time-Fill: this bit determines the interframe time-fill for
HDLC mode:
IFTF = 0:AEH characters are sent as interframe time-fill
IFTF = 1:FFH characters are sent as interframe time-fill.
FRDA: First Receive Descriptor Address points to the beginning of the
receive data chaining list.
This descriptor is only interpreted with a fast receive abort or a receive jump
or a receive initialization command. It is read but ignored with any other
receive cha nn el com m and .
Table 9
TRV No. of Repetitions Transmission Rate
00
01
10
11
7
3
1
0
600 bit/s
1200 bit /s
2400 bit /s
4.8, 9.6, 19.2, 38.4 kbit/s
PEB 20320
Detailed Register Description
User’s Manual 160 01.2000
FTDA: First Tran smit Descri ptor Add ress p oints to the begi nning of the transm it da ta
chaining list.
This desc riptor is onl y interpreted with a fast transm it abort or a trans mit jump
or a transmit initialization command. It is read but ignored with any other
transmit channel command.
ITBS: Individual Transmit Buffer Size; for undisturbed transmission an on-chip
transmit buffer with a total size of 64 long words stores the data before
formattin g and transmitt ing. The indiv idual buffer siz e specifies the part of the
on chip transmit buffer allocated to the channel. This allows a variable data
buffer size if NITBS = 0, ITBS has to be set to 0 also; it is then read but
ignored. (see Chapter 2.3).
Figure 80
Channel Specification
ITS08223
00000000000000000000000000
FRDA (First Receive Descriptor Address)
FTDA (First Transmit Descriptor Address)
0TFLAG TRV
Mode
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SFE
IFC
CH
TE
RE
FIR
FIT
NITBS
RI
TI
TO
TA
TH
RO
RA
IFTF
FA
CRC
INV
CS
Interrupt Mask
New ITBS Value
New Xmt. buffer size
(ITBS valid)
Rcv./Xmt.
Rcv. Commands
(RI, RO, RA):
000 Rcv. Clear
Rcv. OFF010 Rcv. Abort011 Rcv. Jump100 Rcv. Init.101 Not Allowed110 Not Allowed111
First Xmt. Commands
(TI, TO, TA):
IFC:
CH:
TE:
RE:
FIR:
FIT:
(R)
(T) Transmitter Interrupt
Receiver Interrupt
Idle/Flag Change (R)
V.110 Frg. Chg. (R)
ERR Interrupt (T)
ERR Interrupt (R)
FI Interrupt (T)
2
(TH = 1) Xmt. Hold
Transparent Mode Flags
Fill code for flags in
transp. mode A (TMA only)
CRC Select
0
1
CRC Generated/Stripped
CRC to/from Data Section
(HDLC mode only)
Inversion
All Rcv. and Xmt. data Bits
in this channel are inverted.
CRC Polynom
0
1
16 Bit CRC (HDLC mode)
TMB
TMR 1
0
Interframe
Timefill
0
17E
FF
Mode
0 0 TMA
0 1 TMB/TMR
1 0 V.110/X30
1 1 HDLC Mode
Flag Adjustment/Filtering
FNUM interframe timefill
characters in HDLC mode,
or TFLAG filtering in TMA
Transmission Rate of V.110/X30
0 0
0 1
1 0
1 1
600 bit/s, 7 Repetitions
4.8, 9.6, 19.2, 38.4 kbit/s,
no Repetition
ITBS(buffer size)
(ones)
(flags)
(HDLC mode)
Short Frame (R)SFR:
Commands
001 Fast Rcv. Abort
FI Interrupt (R)
Fast Xmt. Abort001
111 Not Allowed
110 Not Allowed
101
100
011
010 Xmt. OFF
Xmt. Clear000
Xmt. Abort
Xmt. Jump
Xmt. Init.
nd Xmt. Commands
:
32 Bit CRC (HDLC mode)
1200 bit/s, 3 Repetitions
2400 bit/s, 1 Repetitions
PEB 20320
Detailed Register Description
User’s Manual 161 01.2000
4.2.6 Current Receive and Transmit Descriptor Address
For easie r monitoring of the link lists the address es of the just proc essed de scriptors are
written into the CCS. MUNICH32 changes the current descriptor address at the same
time when it branches to the next descriptor.
31 16 15 0
Current Receive Descriptor Address Channel 0
.
.
.
Current Receive Descriptor Address Channel 31
Current Transmit Descriptor Address Channel 0
.
.
.
Current Transmit Descriptor Address Channel 31
PEB 20320
Detailed Register Description
User’s Manual 162 01.2000
4.3 Transmit Descriptor
FE: Frame End; this bit is valid in all modes.
It indicates that after sending the data in the transmit data section
– the dev ice gene rates a n inter rupt with FI bit set for HDLC, TM B, TMR, TMA
ERR bit set for V.110/X.30
– the device then sends
• (FNUM + 1) × 7EH for HDLC, IFTF = 0
• 7E, (FNUM –1) × FFH, 7E for HDLC, IFTF = 1, FNUM ≥ 1
• 7E for HDLC, IFTF = 1, FNUM = 0
• (FNUM + 1) × 00Hfor TMB, TMR (FNUM ≥ 1)
• 000Hfor TMR, FNUM = 0
• (FNUM + 1) × TFLAG for TMA, FA = 1
• (FNUM +1) × FFHfor TMA, FA = 0
• three frames with synchronization errors for V.110/X.30
before sta rtin g with the data of t he next trans mit de sc rip tor. If th e
data of the next transmit descriptor are not available in time (e.g.
because the descriptor has FE and HOLD set) the device sends
the interframe time-fill indefinitely.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
FE HOLD HI NO
Transmit Data Pointer
Next Transmit Descriptor Pointer
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
V.110 0 0 0 CSM FNUM
Transmit Data Pointer
Next Transmit Descriptor Pointer
PEB 20320
Detailed Register Description
User’s Manual 163 01.2000
HOLD: If the MUNICH32 detects a hold bit it
– generates an interrupt with ERR bit set if FE = 0 or V.110/X.30 mode
– sends the data in the current transmit data section
– generates the FCS bits for HDLC and CS = 0 and CSM = 0
– the device then sends at least
• (FNUM + 1) × 7EH for HDLC, IFTF = 0
• 7E, FNUM × FFH for HDLC, IFTF = 1
• (FNUM + 1) × 00H for TMB, TMR (FNUM ≥ 1)
• 0000H for TMR, FNUM = 0
• (FNUM + 1) × TFLAG for TMA, FA = 1
• (FNUM + 1) × FFH for TMA, FA = 0
• three frames with synchronization errors for V.110/X.30.
– It polls the HOLD bit and the next transmit descriptor address, but does no
branch to a new descriptor until the HOLD bit is reset. The next transmit
descriptor address is read but not interpreted as long as HOLD = 1.
Therefore it can be changed together with setting HOLD = 0.
The polling occurs at most every 8 valid clock cycles of the channel and
corresponds with internal requests from TF to TB.
– The device send s inte rfram e tim e-fi ll unt il HOLD = 0 is polled .
The HOLD condition is also discarded if a transmit jump, fast transmit abort
or transmit initialization command is detected during the polling. The
MUNICH32 then branches to the transmit descriptor determined by FTDA
even though the HOLD bit of the current transmit descriptor may still be ‘1’.
HI: Host initiated Interrupt; if the HI bit is set, MUNICH32 generates an interrupt
with set HI bit after transferring all data bytes.
NO: This b yte numb er defines the numb er of bytes stored in the data s ection to be
transmitted. A transmit descriptor and the corresponding data section must
contain at least either one data byte or a frame end indication.
Otherwise an interrupt with set ERR bit is generated.
V.110: This bit indicates that in the corresponding data section the E-, S- and X-bits
of the foll owing V.110/X.30 frame are stored. MUNICH32 reads these bits and
inserts them into the next possible V.110/X.30 frame. The data section may
contain only two bytes specified in the next figure.
The first transmit descriptor after a transmit initialization channel command
must have thi s bi t set if it revives the channel from a tra ns mi t off co ndi tio n or
after a pulse at the reset pin.
PEB 20320
Detailed Register Description
User’s Manual 164 01.2000
Intel Mode
Motorola Mode
CSM: CRC Select per Message: This bit is only valid in HDLC mode with CS = 0 and
only in conjunction with the FE bit set. If set, it means that no FCS is
generated automatically for the frame finished in this transmit descriptor.
FNUM: FNUM denotes the number of interframe time-fill characters between
2 HDLC or TMB frames. For X.30/V.110 these bits have to be set to ‘0’.
FNUM = 0 mea ns that after the cu rrent fram e only 1 char acter (7EH for HDLC
and 00H for TMB, 000H for TMR, TFLAG, TFLAG for TMA, FA = 1; FFH for
TMA, FA = 0) is sent before the following frame (shared flags).
FNUM = 1 means that after the current frame 2 characters (7EH 7EH for HDLC
and 00H 00H for TMB and TMR, TF LAG, TFLAG for TM A, FA = 1; FF FFH for
TMA, FA = 0) are sent before the following frame (non shared flags).
FNUM = 2 means that after the current frame 3 characters (7EH 7EH 7EH
(IFTF = 0) or 7 EH FFH 7EH (I FTF = 1) for HDLC and 00H 00H 00H for TMB and
TMR, TFLAG, TFLAG, TFLAG fo r TM A, FA = 1 ; FF FF FFH for TMA, FA = 0)
are sent.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
E7E6E5E4E3E2E1SBSAX000000
15141312111098 7 6543210
0 0000000 0 0000000
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0000000000000000
15141312111098 7 6543210
SAX000000E7E6E5E4E3E2E1SB
PEB 20320
Detailed Register Description
User’s Manual 165 01.2000
FNUM = k means that after the current frame k + 1 characters are sent
(k + 1) times 7EHfor ITFT = 0 and HDLC
7EH, (k – 1) times FFH, 7EHfor ITFT = 1 and HDLC
(k + 1) times 00Hfor TMB, TMR
(k + 1) times TFLAG for TMA, FA = 1
(k + 1) times FFH for TMA, FA = 0.
For HDLC mode FNUM is reduced by one eight of the number of zero
insertions if FA is set. If the reduction would result in a negative number of
interframe time-fill characters it is set to 0.
Transmi t Data Pointer: This 32-bit pointe r contains the s tart address of the transmit da ta
section. Although MUNICH32 works only long word oriented, it
is possible to begin a transmit data section at an uneven
address. The two l east sig nificant bits (ADD) of the transmit data
pointer determine the beginning of the data section and the
number of data bytes in the first long word of the data section,
respectively.
AD D: 00 = 4 by tes
01 = 3 bytes
10 = 2 bytes
11 = 1 byte
MUNICH32 reads the first long word and discards the unused
least sign ificant bytes . The NO estab lishes (de termines ) the end
of the data section, whereas the remainder of
I (NO ADD) ÷4 I defines the number of bytes in the last
long word of the data section.
MUNICH32 reads the last long word and discards the unused
most significant bytes of the last long word.
If the first access is the same as the last access, ADD specifies
the beginning of the data section and NO the number of data
bytes in the long word. All unused bytes are discarded.
PEB 20320
Detailed Register Description
User’s Manual 166 01.2000
For example (Intel mode):
1) ADD = 01, NO = 8
2) ADD = 00, NO = 8
3) ADD = 10, NO = 1
For example (Motorola-mode):
1) ADD = 01, NO = 8
2) ADD = 00, NO = 8
3) ADD = 10, NO = 1
11 10 01 00
byte 2 byte 1 byte 0 –
byte 6 byte 5 byte 4 byte 3 3 long words are read
–––byte 7
11 10 01 00
byte 3 byte 2 byte 1 byte 0
byte 7 byte 6 byte 5 byte 4 2 long words are read
––––
11 10 01 00
–byte 0 ––
––––1 long word is read!
––––
11 10 01 00
–byte 0 byte 1 byte 2
byte 3 byte 4 byte 5 byte 6 3 long words are read
byte 7 –––
11 10 01 00
byte 0 byte 1 byte 2 byte 3
byte 4 byte 5 byte 6 byte 7 2 long words are read
11 10 01 00
––byte 0 –1 long word is read!
PEB 20320
Detailed Register Description
User’s Manual 167 01.2000
Next Transmit This 32-b it pointe r contain s the st art addre ss of the next trans mit
Descriptor Pointer: descriptor. After sending the indicated number of data bytes,
MUNICH32 branches to the next transmit descriptor to continue
transmission. The transmit descriptor is read entirely at the
beginning of transmission and stored in an on-chip memory.
Therefore all information in the next descriptor must be valid
when MUNICH32 branches to this descriptor when HOLD = 0.
For HOLD = 1 the next transmit descriptor pointer is polled
together with HOLD; the next transmit descriptor must be valid,
when HOLD = 0 is polled.
This pointer is not used if a transmit jump, fast transmit abort or
transmit initialization channel command is detected while the
MUNICH32 still reads data from the current transmit descriptor
or polls the HO LD bi t. In th is c as e FTDA is us ed as a poi nte r for
the next transmit descriptor to be branched to.
PEB 20320
Detailed Register Description
User’s Manual 168 01.2000
4.4 Receive Descriptor
The receiv e descriptor contain s 4 long words; the first, third and fou rth have to be written
by the CPU, the second is written by the MUNICH32 when it branches to the next receive
descriptor or when it starts polling the HOLD bit.
Note: The MUNICH32 branches to a next descriptor without writing the second long
word if the receive initialization command is used during normal operation (see
Chapter 4.2.4)
HOLD: Setting the HOLD bit by the host prevents the device from branching to the
next descriptor. The current data section is still filled.
–Afterwards the second descriptor long word is written by the MUNICH32.
For HDLC, TMB, TMR the FE and C-bit is set. If the frame could not
completely be stored into the data section the RA bit is set in the status.
An inte rrupt with set FI bit is gene rated, and in cas e the frame was aborted,
the ERR bit is also set.
For TMA, V.110/X.30 the C-bit and the RA bit is set and an interrupt with
set ERR but with FI = 0 is generated.
–Afterwards the device starts polling the HOLD bit, received data, and
received events normally leading to interrupts (with RT = 1) are discarded
until HOLD = 0 is polled. Each 1 …4 byte data word or interrupt event
normally leading to an access now results in a poll cycle.
Whenever HOLD = 1 is polled the next receive descriptor address is read
but ignored.
–When HOLD = 0 is polled
•for HDLC, TMB, TMR the device continues to discard data until the end
of a received frame or an event leading to an interrupt (with RT = 1) is
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0HOLDHI NO
FE C 0 BNO
Receive Data Pointer
Next Receive Descript or Pointer
15141312111098 7 6543210
0 0000000 0 0000000
Status 0 0000000
Receive Data Pointer
Next Receive Descriptor Pointer
PEB 20320
Detailed Register Description
User’s Manual 169 01.2000
detected. Afterwards the next received frame is transferred into the next
receive descriptor. Interrupts are also generated again.
•For V.110/X.30, TMA the device puts the next data into the next receive
descriptor. Interrupts are also generated again.
The HOLD condition is also discarded upon detection of a receive jump, fast
receive abort or receive initialization command. The MUNICH32 then
branches to the receive descriptor determined by FRDA even though the
HOLD bit in the current receive descriptor may still be ‘1’.
HI: Host initiated interrupt; if the HI bit is set, MUNICH32 generates an interrupt
with set HI bit after receiving all data bytes.
NO: This byte n umber defin es the si ze of the recei ve data sect ion alloc ated by the
host. Because MUNICH32 always writes long words the number of bytes
(data section size) must be a multiple of 4 and greater or equal to 4. The
maximum data section size is 8188 bytes.
After reception of an HDLC frame with a data byte number not divisible by 4
MUNICH32 first transfers the gre atest entire ([number of data bytes/4 ]) in long
words. Then the remainder of the data bytes is transferred in another long
word, where the non-significant bytes are filled with random values. They
should not be interpreted.
For example a HDLC frame with one data byte is received:
The data b yte s are stored into the r ece iv e d ata s ec tio n a cc ord ing to t he Little
Endian convention (Intel mode) or Big Endian convention (Motorola mode).
FE: Frame End: The frame end bit is ‘1’ only in HDLC, TMB, TMR mode and
indicates th at a re ceive fram e has ended in this receive descriptor. For TMA,
V.110/X.30 the bit is always ‘0’.
FE = 0 in HDLC, TME, TMR mode means that frame continues in the next
receive descriptor or that it filled t he current receive data section exactly (BNO
= NO). In this case the next receive descriptor will have FE = 1, C = 1, BNO
= 0 and no data bytes are stored in the corresponding data section.
C: This bit is set by MUNICH32 if
•it completes filling the data section normally (BNO = NO) ⇒FE = 0,
status = 00
•it was aborted by a fast receive abort channel command ⇒ sta tus = 02
00000000.00001000.00000000.00000
11000000.00000001.Status.00000000
receive data pointer
next receive descriptor point er
Receiv e Desc rip t or
XX.XX.XX.data
Receive Data Section
PEB 20320
Detailed Register Description
User’s Manual 170 01.2000
•for HDLC, TMB, TMR if the end of a frame was stored in the receive data
section ⇒FE = 1, status gives the receive status determined by RD
(interrupt with set FI bit is generated)
•for V.110/X.30 mode if the 3 contiguous frames with errors in the
synchronization pattern are received ⇒ FE = 0, status = 20 or status = 21
interrupt with set ERR bit
•for V.110/X.30 mode if the data could not be transferred to the shared
memory due to RB buffer inaccessibility ⇒FE=0, status=01 or
status = 21 interrupt with set ERR bit.
C indicates that the second long word of the receive descriptor was written
by the MUNICH32. Afterwards the MUNICH32 writes the next receive
descriptor address into CCS. Then it branches to this descriptor
immediately.
BNO: MU NIC H32 wr ite s the n umbe r of data byte s it has s tore d in t he c urre nt d ata
section into BNO.
Status: The MUNIC H32 w ri tes th e s tatus inform atio n i nto the statu s b yt e whe nev er it
sets the C-bit. If the status information is not 00 or 40 an interrupt with ERR
bit set is generated. The status is then a means to locate or analyze the
receive error .
The following table gives a general overview over the different status bits in
relation to the channel modes.
HDLC CS = 0
0NI0ILNILI II
HDLC CS = 1
000ILNILI II
V.110/X.30
00I0 00 IFI
TMB0000 ILI IFI
TMR0000 ILI IFI
TMA0000 00 IF0
Where ‘0’ means that in the corresponding mode the bit is always ‘0’. It should not be
interpreted though to be upward compatible to future versions.
76543210
0 SF LOSS CRCO NOB LFD RA ROF
PEB 20320
Detailed Register Description
User’s Manual 171 01.2000
NI means the bit may be ‘1’ or ‘0’ but does not cause an interrupt with
set ERR bit.
ILN means tha t i t m ay be ‘1’ or ‘0’ but sh ould not be evaluated if LFD or NOB
is also ‘1’.
IL means that it may be ‘1’ or ‘0’ but should not be evaluated if LFD = 1.
I means that it may ‘1’ or ‘0’.
IF means that i t may be ‘1’ onl y after a fast re ceive abort c hanne l comm and
or detection of a HOLD bit in the current receive descriptor.
I, IF, IL, ILN lead to an interrupt with ERR bit set.
Note: For HDLC, TMB, TMR the status word is only valid if the FE bit is set.
The meaning of the individual status bits is as follows:
SF = 1 (HDLC mode with CS = 0 only):
The device has received a frame with
≤ 32 bit between start flag and end flag or end abort flag for CRC16
≤ 48 bit between start flag and end flag or end abort flag for CRC32
i.e. BNO was 1 or 2.
LOSS = 1 Three contiguous frames with errors in the synchronization pattern were
detected.
CRCO = 1 A frame with a CRC error was d etected CRCO = 0 means th e frame had
no CRC error.
NOB = 1 A frame whose b it conten t was not divisi ble by 8 was dete cted.
NOB = 0 means that the frame content was divisible by 8.
LFD = 1 Long frame detected. If this bit is set a frame whose bit content
was > MFL was detec ted and aborted . The receptio n will be conti nued as
soon as a flag is recognized.
RA = 1 Receive Abort; this bit indicates that
for HDLC: the frame was ended by an abort flag (7FH) or by a receive
abort command or a fast receive channel command or by a HOLD bit in
the current receive descriptor.
for V.110/X.30, TMB, TMR, TMA that the frame or data were aborted by
a fast receive abort channel command or a HOLD bit set in the current
receive descriptor.
ROF = 1 An overflow of the internal buffer RB has occurred and lead to a
loss of data.
Note: If ROF without FO interrupt is generated for a channel
•for HDLC, TMB, TMR only the last part of one frame has been lost.
•For V.110/X.30 only data but no status information (change E-, S-, X-bits, Loss)
has been lost.
PEB 20320
Detailed Register Description
User’s Manual 172 01.2000
Note: In case of multiple errors all relevant bits are set.
In case of ROF = 1 onl y the e rror conditions of the f rame within which the ov erflow
occurred are reported. Later frames that are aborted do not change the status.
Receive Data Pointer: This 32-bit pointer contains the start address of the
receive data section.
Receive Descriptor Pointer: This 32-bit pointer contains the start of the next receive
descriptor.
It is not used if a receive jump, fast receive abort or
receive initialize command is detected while the
MUNICH32 still writes data into the current receive
descriptor or polls the HOLD bit. In this case FRDA is
used as a pointer for the next receive descriptor to be
branched to.
PEB 20320
Application Notes
User’s Manual 173 01.2000
5 Application Notes
5.1 Test Loops
5.1.1 Test Loop Definitions for the MUNICH32
Two basic types of test loops are provided by the MUNICH32, internal and external.
Each of these types is further sub divid ed into cha nnelwis e and com plete tes t loops thu s
providing four possible test loops.
5.1.1.1 Internal Complete Test Loop
The serial data output is physically routed to the serial data input. The TX data appears
on the TDATA output pin and the RDATA input pin is ignored. TCLK and RCLK have to
be identical; TSP and RSP have to be identical. The logical Transmit and Receive
channels have to be programmed identically.
Figure 81
ITS08198
TDATA
1
&
CD
RDATA
µP Interface
Enable Int.
Complete Loop
&
RSP
RCLK
TCLK
TSP
PEB 20320
Application Notes
User’s Manual 174 01.2000
5.1.1.2 Internal Channelwise Test Loop
One (and only one) logical channel is mirrored from the serial data output to the serial
data input. The other logical channels are not affected by this operation. The transmit
and receive data rates for this single logical channel must be identical. Normal TCLK,
RCLK, TSP and RSP design rules apply. This test loop provides channelwise testing
capabilities during idle channel time slots, without interfering with normal data
transmission/reception.
Figure 82
5.1.1.3 External Complete Test Loop
The seri al data input i s physically r outed to the serial data ou tput. Data is rec eived on the
RDATA pin and routed to the TDATA pin. The received data can be stored in shared
memory for additional diagnostic purposes. TCLK and RCLK have to be identical; TSP
and RSP have to be identical.
ITS08199
TDATA
1
&
CD
Channel X only
RDATA
µP Interface Enable Int.
Channelwise Loop
for Channel X
PEB 20320
Application Notes
User’s Manual 175 01.2000
Figure 83
5.1.1.4 External Channelwise Test Loop
One (and only one) logical channel is mirrored from the serial data input to the serial
data output. The other logical channels are not affected by this operation. The receive
and transmit data rates for this single logical channel must be identical. Normal TCLK,
RCLK, TSP and RSP design rules apply. This test loop provides channelwise testing
capabi lities duri ng idle channel time slots , without interf ering with normal data recep tion/
transmission.
Figure 84
ITS08200
TDATA
1
&
CD
RDATA
µP Interface
Enable Ext.
Complete Loop
&
RSP
RCLK
TCLK
TSP
ITS08201
TDATA
1
&
CD
Channel X only
RDATA
µP Interface Enable Ext.
Channelwise Loop
for Channel X
PEB 20320
Application Notes
User’s Manual 176 01.2000
5.1.2 Test Loop Activation
All of the tes t lo ops are c los ed (activated) and ope ned (deac ti va ted) by setting/r ese tting
the appropriate combination of bits in the Action Specification (Table 10). Any unl ist ed
combination of LOC, LOOP and LOOPI is an invalid operation. Although the data sheet
(Data Sheet 08.93) specifically states that loops must be left (opened) by issuing the
reset p in to ‘1’, there are exception s to this rule. Ge nerally, the test loo ps can be opene d
by soft ware. There a re several c ases that mus t be examin ed and these will be disc ussed
in the next section.
When closing (activating) a test loop, the IN, ICO, IM, RES, and IA bits should equal ‘0’
and PCM and MFL should be set to the appropriate values.
The following recommended procedure for activating a test loop assumes that the
MUNICH32 has been fully initialized and the user desires to activate a test loop on
channel x:
•Initialize Rc and Tx channel as appropriate for type of test loop.
•Close (activate) the test loop.
•Perform test functions (transmit/receive data, check for interrupts, errors, etc.)
•Open (deactivate) the test loop.
•Perform Rc and Tx off function.
Note: While the test loop is activated, do not execute the transmit off command. It will
not have the effect of resetting the transmit formatter.
5.1.3 Test Loop Deactivation and Switching
As mentioned previously, a test loop can be opened (deactivated) by software. To
deactiv ate a test loop a new ASP should be issued with L OC, LOOP, and LOOPI = 0 and
all other bits should be set to the previous values used during activation. Listed below
are the possible test loop operations that can be activated with software and those
requiring a hardware reset. Table 11 is provided as a graphical representation of this
information.
Table 10
Test Loop Activation
Test Loop LOC LOOP LOOPI ASP
Intern al co mpl e te 0 0 1 x xx xx x0 8H
Intern al ch annelwise 1 0 1 xxxxxx2 8H
Extern al complete 0 1 0 xxx xx x1 0 H
Extern al channelwi se 1 1 0 xxx xx x3 0 H
No loop 0 0 0 xxx xx x00H
PEB 20320
Application Notes
User’s Manual 177 01.2000
5.1.3.1 Software Op er atio ns
Close and open internal complete loop.
Close and open internal channelwise loop.
Close and open external complete loop.
Close and open external channelwise loop.
Change from internal complete loop to internal channelwise loop.
Change from external complete loop to external channelwise loop.
5.1.3.2 Hardware Re se t Operati ons
Change between the internal complete loop and external complete loop.
Change between the internal channelwise loop and external channelwise loop.
Change between the internal channelwise loop and internal complete loop.
Change between the external channelwise loop and external complete loop.
Change between internal channelwise loop and external complete loop.
Change between internal complete loop and external channelwise loop.
Change between external channelwise loop and internal complete loop.
Change between external complete loop and internal channelwise loop.
Table 11
Allowed Operations
Change to
Internal
Complete
Loop
Internal
Channelwise
Loop
External
Complete
Loop
External
Channelwise
Loop
Internal
Complete Loop XSFW HDW Reset
required HDW Reset
required
Internal
Channelwise
Loop
HDW Reset
required XHDW Reset
required HDW Reset
required
External
Complete Loop HDW Reset
required HDW Reset
required XSFW
External
Channelwise
Loop
HDW Reset
required HDW Reset
required HDW Reset
required X
PEB 20320
Application Notes
User’s Manual 178 01.2000
5.1.4 Test Loop Examples
5.1.4.1 Internal Channelwise Test Loop
Generate HW RESET, and hold off RSP/TSP for 1000 SCLK cycles.
ASP: A104-80 04 ;CEPT , MFL=260 , IN , IA=1
IQS: ICQ
0000-001F
TSA[0]: 00FF-00FF ;TS0 = CH0
TSA[1…31]: 0000-0000 (×31)
CSP[0]: 00E9-0006 ;Tx/Rc init, poll Tx Desc, HDLC
FRDA
FTDA
0000-0002 ;ITBS = 2 long words
CSP[1…31] 0000-0000 0000 -0 000 0000-0 000 0000-0 00 0 (x31)
CRA[0…31] 0000-0000 (×32)
CTA[0…31] 0000-0000 (×32)
ICQ: 0000-0000 (×512)
FRDA: 0020-0000
0000-0000
RcvDtaPtr → 32 by te
+ NxtRDPtr data bl oc k
+→ 0020-0000
0000-0000
RcvDtaPtr → 32 by te
+ NxtRDPtr data bl oc k
+→ 0020-0000
0000-0000
RcvDtaPtr → 32 by te
+ NxtRDPtr data bl oc k
+→ 4020-0000 ;HOLD = 1
0000-0000
RcvDtaPtr → 32 by te
0000-0000 data bloc k
FTDA: C000-0000 ; HOLD, FE = 1 for dummy frame
XmtDtaPtr
+ NxtTDPtr
+→ 0020-0000
XmtDtaPtr → abcdefghijklmnop
+ NxtTDPtr qrstuvwxyz012345
+→ C020-0000 ;FE, HO LD = 1
XmtDtaPtr → ABCDEFGHIJKLMNOP
0000-0000 QRSTUVWXYZ987654
PEB 20320
Application Notes
User’s Manual 179 01.2000
Generate AR Pulse and wait for INT signal (set up TS0 and CH0).
Read interrupt queue:
ICQ: 9000-8000 ;Action Request Acknowledge
;V2.2 (V2.1 = 8800-8000)
9000-1000 ;Polls HOLD bit of 1st Tx Desc.
Set ASP for Inter na l Channel wise Loop tes t
ASP: A104-0 028 ;CEPT , MFL=260 , In t. Chnl loo p
Generate AR Pulse and wait for INT signal.
Read interrupt queue:
ICQ: 9000-8000 ;Action Request Acknowledge
9000-1000 ;Polls HOLD bit of 1st Tx Desc.
9000-082020 ;Rc ITF state change
Clear HOLD bit in FTD A (allow fr ame to Tx ove r Int ernal Ch nl . Loop).
Read interrupt queue:
ICQ: 9000-1 000 ;En d of Tx frame, po ll ing HOLD
bit of Tx desc.
9000-1020 ;Rc frame complete
Read receive descriptors:
FRDA: 0020-0000
4020-0000 ;C = 1, NO = BNO
RcvDtaPtr → abcdefghijklmnop
+ NxtRDPtr qrstuvwxyz012345
+→ 0020-0000
4020-0000 ;C = 1, NO=BNO
RcvDtaPtr → ABCDEFGHIJKLMNOP
+ NxtRDPtr QRSTUVWXYZ987654
+→ 0020-0000
C000-0000 ;FE, C = 1, BNO = 0
RcvDtaPtr → ;empty! (p. 139 User’s Manual -
FE description)
+ NxtRDPtr
+→ 4020-0000
0000-0000
RcvDtaPtr → 3 2 by te
0000-0000 data bloc k
PEB 20320
Application Notes
User’s Manual 180 01.2000
5.1.4.2 External Channelwise Test Loop
Generate HW RESET, and hold off RSP/TSP for 1000 SCLK cycles.
ASP: A104-80 04 ;CEPT , MFL=260 , IN , IA=1
IQS: ICQ
0000-001F
TSA[0]: 00FF-00FF ;TS0 = CH0
TSA[1…31]: 0000-0000 (×31)
CSP[0]: 00E9-0006 ;Tx/Rc init, poll Tx desc., HDLC
FRDA
FTDA
0000-0002 ;ITBS = 2 long words
CSP[1…31] 0000-0000 0000-0000 0000-0000 0000-0000 (x31)
CRA[0…31] 0000-0000 (×32)
CTA[0…31] 0000-0000 (×32)
ICQ: 0000-0000 (×512)
FRDA: 0020-0000
0000-0000
RcvDtaPtr → 32 by te
+ NxtRDPtr data bl oc k
+→ 0020-0000
0000-0000
RcvDtaPtr → 32 by te
+ NxtRDPtr data bl oc k
+→ 0020-0000
0000-0000
RcvDtaPtr → 32 by te
+ NxtRDPtr data bl oc k
+→ 4020-0000 ;HOLD = 1
0000-0000
RcvDtaPtr → 32 by te
0000-0000 d at a block
FTDA: +→ C000-0000 ;HOLD , FE = 1 for dummy fra me
XmtDtaPtr
+ NxtTDPtr
PEB 20320
Application Notes
User’s Manual 181 01.2000
Generate AR Pulse and wait for INT signal (set up TS0 and CH0).
Read interrupt queue:
ICQ: 9000-8000 ;Action Request Acknowledge
;V2.2 (V2.1 = 8800-8000)
9000-1000 ;Polls HOLD bit of 1st Tx Desc.
9000-1000 ;FI Frame indication for the
1st Tx Desc.
;Now M32 start s po lling HOL D
bit of 1st Desc.
Set ASP for Exter na l Channel wise test loo p
ASP: A104-0 030 ;CEPT, MFL=2 60 , Ext. Chnl loop
Generate AR Pulse and wait for INT signal.
Read interrupt queue:
ICQ: 9000-8000 ;Action Request Acknowledge
9000-0820 ;Only if other st ation uses
idle code 7E
9000-1020 ;Received frame complete
Read receive descriptors: ;assumes 64 byte frame externally looped
FRDA: 0020-0000 ;with proper HD LC framing
4020-0000 ;NO = BNO
RcvDtaPtr → abcdefghijklmnop
+ NxtRDPtr qrstuvwxyz012345
+→ 0020-0000
4020-0000 ;NO=BNO
RcvDtaPtr → ABCDEFGHIJKLMNOP
+ NxtRDPtr QRSTUVWXYZ987654
+→ 0020-0000
C000-0000 ; FE , C = 1, BNO = 0
RcvDtaPtr → ;empty!
+ NxtRDPtr
+→ 4020-0000
0000-0000
RcvDtaPtr → 32 by te
0000-0000 d at a block
PEB 20320
Application Notes
User’s Manual 182 01.2000
5.2 MUNICH32 in a LAN/WAN Router
5.2.1 Introduction
Subject of this application note is an ISDN/LAN Router, a communication system that
enables two LANs to communicate via the ISDN.
Figure 85
ISDN/LAN Router
The st ruct ure of the w hol e sy st em is sh ow n in Figure 85. The router itself is rea liz ed as
a stand alone solution. It is connected to a standard PC for software download and
mainten an ce con trol on ly . Afte r the dow n lo ad t he s ys te m wo rks ful ly in dep end ent of the
hos t PC.
The hardware of the ISDN/LAN router consists of an application specific part and a
processor system. The application specific hardware is mainly based on the SIEMENS
Component MUNICH32 (Multi Channel Network Interface Controller for HDLC) and a
standard LAN controller. Both devices are integrated in the same processor system.
The software of the ISDN/LAN router is formed by integrating the MUNICH32 Device
Driver Module (DDM) and the corresponding LAN controller Device Driver Module in a
Device Driver System (DDS). The device driver modules build a platform to implement
the routing strategy in a separate application module.
The application specific hardware, the MUNICH32 Device Driver Module and the
application module are the main aspects described in the following chapters. The
structure of the processor system is briefly illustrated. The DDS service routines are
explai ned as far a s nec essar y to u ndersta nd thi s sp ecial appli catio n. It i s sug gested that
the reader has some knowledge about the MUNICH32 before reading this application
note. D etailed in formation about the M UNICH32 , its feature s and me mory struc tures are
given in the MUNICH32 PEB20320 Data Sheet.
ITS08283
Router Router
ISDN
LAN LAN
PEB 20320
Application Notes
User’s Manual 183 01.2000
5.2.2 Hardware
The processor system is based on a Motorola 68040 processor. It contains 512 KByte
SRAM, a bus contro lle r and peri phe ral s lik e tim er, EPROM and interru pt co ntrol le r. The
application specific hardware is integrated by using a Peripheral Connector and an
Alternate Busmaster Connector. The Peripheral Connector allows the integration of
external peripherals. The Alternate Busmaster Connector is used to connect external
bus masters to the local bus. The system is provided with a RS232 serial interface to
download executable software on the board.
Figure 86
Hardware Block Diagram
ITB08284
Timer
EPROM
Interrupt
Controller
SRAM
Alternate
Busmaster
Connector Peripheral
Connector
Bus
Controller
MC68040
i82596 MUNICH32
i82C501
EM2
Connector Connector
ACFA
PRACT
RS232
ISDN
Interface Interface
LAN
Glue Logic
LAN ISDN
PEB 20320
Application Notes
User’s Manual 184 01.2000
Application Spec ific Hardw are
The application specific hardware consists of an ISDN primary rate interface and an
Ethernet i nterface. The MUNICH32 PEB 20320 in conjun ction with the la yer 1 SIEMENS
components ACFA (Advanced CMOS Frame Aligner) PEB 2035 and PRACT (Primary
Rate Access Clock Generato r and Transceiver) PEB 22320 are used to build the primary
rate interface. Incoming data from the ISDN is first processed from the PRACT. It
translates the HDB3 coded line signals in dual rail signals. The PRACT also supplies
ACFA and MU NICH32 with clo ck signals . Main task of the ACFA i s the frame ali gnment.
Besides , the ACFA transla tes the dua l rail data in a single rai l, unipolar bit stream w hich
can be processed by the MUNICH32.
The MUNICH32 handles up to 32 channels of a full duplex PCM highway. All time-slots
may have data rates between 8 Kbit/s and 64 Kbit/s. The MUNICH32 supports besides
other protocols the HDLC formatting/deformatting. If programmed for HDLC mode, the
MUNICH32 performs HDLC specific functions like framing, CRC check/generation,
flag stuffing and zero bit insertion/deletion autonomously. An on-chip 64-channel
DMA controller allows the device to store/read data into/from the SRAM. The DMA
controller manages long word or word transfers via a 32-bit processor interface. The
µP interface can be configured to be Motorola 68020 or intel 80386 compatible.
Figure 87
ISDN Interface
The Ethem et inte rface i s bui lt with a LAN c ontrol ler, a Manc heste r enco der/ decoder an d
a transceiver. The LAN controller supports all IEEE 802.3 standards. The Ethernet
framing: preamble generation, source address generation, destination address
checking, short-frame detection, automatic length field handling is performed. After
LAN controller pr ocessing the transmit data is Manchester encoded and forwarded to the
transmi ssio n line, whil e receiv e data is Mancheste r decode d bef ore being process ed by
the LAN controller.
ITS08285
MUNICH32
ACFA PRACT Line IN
Line OUT
Overvoltage
µP Interface PCM
Highway
Dual Rail
Unipolar
Signals
PEB 20320
Application Notes
User’s Manual 185 01.2000
System Architecture
The system architecture is shown in Figure 88. The MUNICH32, the CPU and the
LAN controller store data in the shared memory. The communication between CPU and
alternate bus master i s done vi a the share d memory. The CPU inform s the alternate bus
masters with help of control signals about changes in the shared memory and vice versa.
The MUNICH32 input control signal is the Action Request pulse (ACTION REQUEST).
It is generated by one CPU write cycle to a defined address and decoding the address
lines. The MUNICH32 then responds by generating an interrupt pulse and writing the
respective interrupt information in the SRAM.
Figure 88
System Architecture
ITS08286
MUNICH32
CPU i82596
Signals
Control Control
Signals
Local Bus Shared
Memory
PEB 20320
Application Notes
User’s Manual 186 01.2000
Bus Arbitration
Since three devices are using the bus it is necessary to implement a bus arbitration.
Each bus master requests bus mastership and awaits bus control given to it by the
arbit er. The bus a rbitratio n protocol is also Moto rola spec ific. The in tel speci fic signa ls of
the LAN controller (i82596) are translated into Motorola specific signals. The bus
arbitration is realized in two devices GAL16V8 (15 ns), both containing a Finite State
Machine. Arbiter 1 gives bus mastership to the CPU whenever no other bus master
requests bus mastership. If either the MUNICH32 or the LAN controller requests bus
masters hi p th e a rbi ter 2 give s a bus requ es t to the arbiter 1. Arbiter 1 forces t he CPU to
release the bus and gives bus mastership to arbiter 2. Arbiter 2 then responds to
MUNICH 32 or LAN co ntroller. In this solution the priority of th e MUNICH32 is higher than
that of the LAN controller. Consequently if both alternate bus masters request bus
mastership at the same time, bus mastership will be given to the MUNICH32. The LAN
controll er has to wait until MUNICH32 has finished his accesses and arbiter 1 returns the
bus to the CPU. It might happen, that some Ethernet frames get lost, because the
LAN controller can not get access to the bus in time, but the loss of incoming data from
the ISDN (where fees have to be paid) is minimized.
Figure 89
Bus Arbitration
ITS08287
MUNICH32
CPU i82596
Arbiter 1
Arbiter 2
PEB 20320
Application Notes
User’s Manual 187 01.2000
Bus Timing Adaptation1)
The bus controller manages memory accesses of all bus masters (CPU, MUNICH32 or
LAN controller). The bus controller timing is Motorola 68040 specific. The MUNICH32
bus interface is either Intel specific or Motorola 68020/030 specific. Therefore the
MUNIC H32 bu s ti ming needs to be ad ap ted by us ing simple glu e lo gic . On e G ate Arra y
Logic (Gal16V8, 15 ns) contains all necessary logic.
The MUN ICH32 Address Str obe (AS) sign al determine s valid addres ses on the bus. The
equivalent Motorola 68040 control signal is the Transfer Start (TS). During MUNICH32
write cycles valid data on the bus is indicated with the Data Strobe (DS) signal.
MUNICH32 write and read bus cycles are terminated with the Data Transfer
Acknowledge (DSACK) signal. For the Motorola 68040 the end of a bus cycle is
indicated by the Transfer Acknowledge (TA) signal.
During MUNICH32 bus cycles the MUNICH32 output signal AS is us ed to ge ne r a te t he
bus controller input signal TS. The TS is deasserted with the MUNICH32 input DSACK
rising edge. Since all bus cycles have the same length the DSACK signal is generated
two bus clock cycles after AS is detected low. TS is tristated, if the MUNICH32 is not
busmaster. This signal is driven by another bus master during that time.
Figure 90
MUNICH32 Timing Adaption
1) See also Chapter 5.2.6.
ITD08288
BCLK
SCLK
TS
TA
Addr
Data
AS
DSACK
PEB 20320
Application Notes
User’s Manual 188 01.2000
The LAN controller’s (i82596) bus timing also needs to be adapted. The address lines
A1, AO, Size 0 and Size 1 need to be generated, because the LAN controller performs
8 bit and 16 bit cycles as well as 32 bit cycles. There are also some non standard bus
signal s for the LAN control ler, that have to be generated . Furthermore th e System Clock
and the Bus Clock have to be synchronized. All necessary glue logic for the
LAN controller is realized in four devices Gal 16V8.
5.2.3 Software
The software is based on a message oriented device driver system. The device driver
modules and application modules have a structure that allows to access them via
defined entry points.
Module Entry Points
Two En try poin ts o ffer acce ss to the DDMs . Mes sage s can be sent to t he DD M via the
Message Entry Point. A ha rdware interrupt causes the program to branc h to the Interrupt
Entry Point. The APM also offers access via a Message Entry Point, but since the APM
does not control any hardware, there does not exist any Interrupt Entry Point.
Figure 91
Module Entry Points
ITS08289
Device Driver System
Device Driver Module Application Module
Message Message
Hardware
Interrupt
PEB 20320
Application Notes
User’s Manual 189 01.2000
DDS Tasks
The message transfer between the modules is the main task of the DDS, realized by
some service routines. DDMs and APMs are integrated in the DDS by executing a
Module Init Routine. T he Modu le Init R outi ne is ca lled by the DD S. Additio nally the DDS
offers service routines for memory management. All service routines can be used by all
modules. Some memory management functions will be presented in more detail. For
detaile d inform ation about the othe r DDS s ervice rou tines pleas e refer t o the SIP B 7520
Primary Rate User Board or EASY532 Datacom Userboard Documentation.
Memory Management
With the memory management functions the allocation of message descriptors,
MUNIC H32 recei ve/tran smit desc riptors 1) or LAN controlle r receive/tra nsmit descripto rs
is simplified. During initialization of the memory management module DDSM a pool of
descriptors is prepared in a linked list. The memory management functions allow to
allocate descriptors and to free descriptors. During initialization of the memory
management module DDSM a pool of descriptors is prepared in a linked list. The
memory management functions allow to allocate descriptors and to free descriptors.
During allocation a descriptor is taken from the prepared list. After utilization the
descriptor is given back to the descript or pool. There is one pool for message descriptors
and one pool for MUNICH32 receive/transmit and LAN controller receive/transmit
descriptors. Because MUNICH32 transmit and receive descriptors differ and they both
differ from the LAN controller transmit and receive descriptors, there are service
functio ns ava il abl e to conv ert the des cri pto r type.
1) Refer to MUNICH32 Data Sheet.
PEB 20320
Application Notes
User’s Manual 190 01.2000
Figure 92
Memory Management
ITS08290
Message Descriptor Pool Allocate
Free
Free
Allocate
Convert
MUNICH32/LAN Controller
Descriptor Pool
PEB 20320
Application Notes
User’s Manual 191 01.2000
5.2.3.1 Device Driver Module MUNICH32
Tasks
The MUNICH32 Device Driver Module has to prepare all memory structures for the
MUNICH32. The ACTION REQUEST Pulse has to be generated. The device driver
module also has to treat the MUNICH32 interrupts.
Message Entry Point
Every incoming message results in executing a function.
Function Action
ResetMunich32 Action Specification Reset bit is set, All channels are
initial iz ed, all time-s lo ts are ini tia liz ed , ACTION
REQUEST Pulse is generated.
Conf igMunich32 Sets PC M mode and maximum frame len gth, ACTION
REQUEST Pulse is generated.
InitlnterruptQueue Interrupt Attention bit is set, A new interrupt queue is
defined, ACTION REQUEST Pulse is generated.
InitChannel Action Specification in-bit is set, Initializes receiver and
transmitter of selected channel, ACTION REQUEST
Pulse is generated.
InitTxChannel Initializes transmitter of selected channel, ACTION
REQUEST Pulse is generated.
InitRcChannel Initializes receiver of selected channel, ACTION
REQUEST Pulse is generated.
SendFram e Adds tx de script ors to the tran smit descripto r q ueue a nd
clears hoId bit of poll descriptor if the channel is active.
TxJump If n o poll des criptor is detected Ini tialize C hannel On ly bit
is set, ‘transmit jump’ command is given, if the previous
command was not ‘receive abort’ or ‘off the receive clear’
command is given, ACTION REQUEST Pulse is
generated.
TxHold Initiali ze Chan ne l O nl y b it i s set, turns cha nne l on or off,
turn channel on: if last command was ‘transmit off’ or
‘transmit abort’ ‘transmit clear’ is given and ‘transmit hold’
bit is cleared, turn channel off: if channel is active and
‘transmit hold’ bit is set, ACTION REQUEST Pulse is
generated.
PEB 20320
Application Notes
User’s Manual 192 01.2000
Interrupt Entry Point
The inform ation in the interru pt queue is read and a mes sage containi ng that informatio n
is sent to the user.
In case of a received frame the written receive descriptors are linked to a message and
sent to the user. The next available descriptor in the list is linked to the memory
structures. An equivalent number of new receive descriptors is allocated and linked to
the end of the receive descriptor queue.
In case of a transmit acknowledge interrupt the used transmit descriptors are released
to the descriptor pool.
TxShutDown Initialize Channel Only bit is set, gives ‘transmit off’
command or ‘transmit abort’ command, A CTION
REQUEST Pulse is generated.
RcJump Initialize Channel Only bit is set, If last command was
‘transmit off’ or ‘transm it abo rt ’ ‘transmit clear ’ is given,
‘receive jump’ command is given, ACTION REQUEST
Pulse is generated.
RcShutDown ‘Initialize Channel Only’ bit is set, Gives receive off
command if receiver was aborted otherwise gives
receive abort command, ACTION REQUEST Pulse is
generated.
SwitchlnternalChanLoop Sets/clears Internal Channelwise Loop, ACTION
REQUEST Pulse is generated.
SwitchlnternalCompLoop Sets/clears Complete Loop, ACTION REQUEST Pulse is
generated.
ShowMunich32Versi onN r ACTION REQUEST Pulse is gen erat ed.
CheckActionRequestQueue Looks for messages to be processed and branches to
the Message Entry Point.
Function Action
PEB 20320
Application Notes
User’s Manual 193 01.2000
Programming the MUNICH32 for this Application
The basic programming of the MUNICH32 for this application is realized in the Module
Initialization Routine. Further programming is done by calling the function ‘Init Channel’
for each c hannel once . Transmit data is then added t o the memo ry structures b y passing
a message with linked transmit descriptor(s) to the function ‘Send Frame’.
Module Initialization Routine
Here the IM-bit is cleared because the MUNICH32 DDM expects the action request
acknowledge interrupt. The values for PCM and MFL are set. The PCM format is a 32-
channel format according to CEPT. The maximum frame length is set to its maximum.
Finally the address and length of a new interrupt queue are defined. Those values will
not be changed anymore.
Init Channel Routine
The function ‘Init Channel’ initializes the time-slot assignment and the channel
specification for one channel. The channel number is set to the value of the variable
‘channel’. The MUN ICH32 is alert ed to access all time-s lot assignme nts and the channe l
specification by setting the in-bit.
The fillmask (transmit and receive) for the selected channel is written in the appropriate
word o f th e t ime -sl ot as si gnm en t. Al l o t he r c han nel s and th eir fil lm as ks ar e n ot a ffe cte d.
For this application all interrupts are enabled. Initialization of the selected channel
comprises the definition of a new ITBS value and initialization of the receiver and the
transmitter. The transmit hold bit is cleared. After initialization the MUNICH32 starts
polling the hold bit of the current transmit descriptor. Therefore a transmit descriptor is
allocated and connected to the memory structures. Its hold bit and fe-bit are set to one,
its no-bi ts are se t to zero. For th at reason the MU NICH32 doe s not transm it anythi ng but
polls this descriptor. Since after the receiver’s initialization the MUNICH32 is ready to
receive data, a queue of receive descriptors is allocated and linked to the memory
structure s. The h old bit o f the las t descri ptor in th e list i s set to i ndicate t he en d of the l ist.
In all other descriptors the hold bit is cleared.
PEB 20320
Application Notes
User’s Manual 194 01.2000
Send Frame Routine
Calling ‘SendFrame’ after initialization of a channel results in executing ‘AddHdlcFrame’.
In that routin e the trans mit descr iptors are dis connecte d from the messa ge and linke d to
the memory structures. If the message source is the ‘MROUTE Application Module’ the
hold bit and fe-bit in dicat ing the end of a f rame an d the en d of t he list have a lready bee n
set/cleared in the MROUTE module, they are not modified anymore. If the message
source i s any othe r module th e fe-bit and hold bit are cleared in all descripto rs except for
the last one. There the hold bit has to be set, to prevent the MUNICH32 from branching
to the next de sc rip tor. Se ttin g the fe-bi t in the las t des cri pto r only forc es the M UNI CH32
to send the data in one HDLC frame. The bits HI, V110 and CSM are cleared in both
cases.
Transmit/Receive Interrupt
A transmi t ac k now l edg e in terru pt i s t reated by return in g th e tra nsm it des c ript or(s ) to th e
descrip t or poo l.
After a receive interrupt (FI bit set) the receive descriptors with c-bit set, are
disconnected from the list of receive descriptors, linked to a message and sent to the
MROUTE module. The next free receive descriptor in the list is linked to the memory
structur es. An eq uivalen t number of new des criptors is al locat ed and lin ked to the end of
the receive descriptor list.
5.2.3.2 Application Module MROUTE
The application module MROUTE implements the routing strategy.
Routing Strategy
Both dev ice s the MUNICH 32 and the LAN c on trol ler o rga niz e re ce iv e an d transmit da ta
in a linke d lis t of rec eiv e de sc rip tors and a li nk ed li st of tra ns mi t des cri ptor s. The data is
stored in data buffers of variable size. The receive/transmit descriptors contain the
address of the data buffer. The basic idea behind the routing strategy is, to take the
MUNlCH32’s receive descriptor and link it to the LAN controller’s transmit descriptor
queue. O n the oth er hand to take the LAN controll er’s rece ive desc riptor and link it to the
MUNlCH32’s transmit descriptor queue.
PEB 20320
Application Notes
User’s Manual 195 01.2000
Figure 93
Insertion of additional Information
To make ef fic ien t us e of the ava il abl e ban dw id th, the pa rall el use of severa l B-ch an nel s
is one of the routing strategy’s goals. Every Ethernet frame is divided into several parts
because the LAN controller stores the received data in several receive descriptors, if
necess ary. T he fram e is then s ent v ia the ISDN by u sing a sep arate B-c hanne l for e very
LAN receive descriptor. To ensure that the parts of the Ethernet frame will be
reassem bled in correct or der, every part of the Ethernet fra me is sup plied with additiona l
information. That additional information has to be extracted before reassembling the
fram e. In Figure 93 an exam ple of one Eth ernet fra me cons isting of three des cripto rs,
spread over two B-channels, is shown. The additional information contains the frame
number, th e desc riptor nu mber an d the info rmatio n, whe ther the fra me is com pleted . To
simplify the extraction of the additional information every frame part and its additional
information are sent in one HDLC frame.
ITS08291
0
Frame
Count Descr
Count
EOF= 0 1=EOF Count
Descr
Count
Frame 2
fe = SET SET=fe
Ch1
2Ch
SET=fe
1=EOF Count
Descr
Count
Frame 1
012
EOF= SET
ISDN
64 kbit/s
each Channel max 10 Mbit/s
LAN
PEB 20320
Application Notes
User’s Manual 196 01.2000
The fe-bit ma rks the en d of one HDL C frame, the EO F bit marks the end of the Ethern et
frame. The ad dition al inform ation comprises the 8-bit word de scrip tor count , 16-bit word
frame count and EOF a 8-bit variable which indicates the last descriptor of the frame.
Message Entry Poin t
The mes s age en try poi nt calls two function s: Isd nR ou teFra me an d LanRoute Frame. An
Ethernet frame is processed by IsdnRouteFrame, an ISDN frame by LanRouteFrame.
The MUN ICH32 recei ve desc riptors are converted to LAN c ontroller t ransmit d escriptors
and those of the LAN controller are converted to MUNICH32 transmit descriptors.
Figure 94
Message Flow between DDMs and MROUTE Module
Besides the IsdnRouteFrame realizes the insertion of additional information and splits
an E thernet frame on several B-channels. The addition al information is stored in an ex tra
allocated transmit descriptor which is placed before the descriptor containing the data.
Every descriptor and the respective extra descriptor are connected to one message
descriptor. This message with set hold bit and set fe-bit in the descriptor containing the
data is further processed from the MUNICH32 DDM routine ‘Send Frame’.
LanRouteFrame reassembles the Ethernet frames. It takes into account, that the parts
might arrive with different delays. Every complete frame is connected to a message
des c riptor and than processed from the LAN controller DDM.
MUNICH32
DDM DDM
LAN Controller
ISDN Route Frame
LAN Route Frame
MROUTE Module
MUNICH32
TX Descr
RC Descr
MUNICH32
Message Descr
TX Descr
LAN Controller
RC Descr
LAN Controller
Message Descr
ITS08292
PEB 20320
Application Notes
User’s Manual 197 01.2000
5.2.4 Performance Considerations
Some considerations about the performance are made by investigating the maximum
data rate. Further investigations are made about the bus occupancy by all busmasters
and the M UNICH 32 poll ac cess’ infl uence on t he data rate. Final ly the proces sing of on e
frame is illustrated.
Data Rates
The data rate during transmission from the ISDN into the Ethernet was tested.
Figure 95
Data Rate
The size of one data buffer is 128 Byte. If the number of channels exceeds 24 the data
rate depends on the MUNICH32 transmitter. If the transmitter is initialized the data rate
dec reases. This shows the in fluence of the MUNICH32 polling the Hold bit.
ITD08293
036912151821242730 Channels0
200
400
600
800
1000
1200
1400
1600
1800
2000
kbit/s
Data Rate available
Data Rate without
MUNICH32 polling
Data Rate with MUNICH32
polling
PEB 20320
Application Notes
User’s Manual 198 01.2000
Bus Occupancy
The bus oc cupancy during norm al operatio n is show n in Figure 96. In this case the da ta
buffer size was 32 Byte. The CPU has busmastership during 90% of the time. The
MUNICH32 as well as the LAN controller, each have busmastership 5% of the time.
The bus occupancy of the MUNICH32 is calculated to 2.5%1). In this system it is higher
becaus e of insert ed wait s tates in e very b us cycle. An other rea son is the bu s controll er’s
clock which is swit ched fro m 33 MHz to 40 MHz. This an d the exi stence of t wo alt ernat e
bus masters results in a more time consuming arbitration protocol than that needed for
a simpler architecture.
Figure 96
Bus Occupancy
1) Compare Data Sheet.
ITD08294
i82596
5 %
M32
5 %
CPU
90 %
PEB 20320
Application Notes
User’s Manual 199 01.2000
MUNICH32 Polling
The influence of the polling can be illustrated by showing the bus occupancy of
MUNICH32 poll accesses only.
Figure 97
Bus Occupancy During Polling
Here the MUNICH32 is polling 31 channels (= 31 × 2 read accesses during 125 µs).
Every ac cess is 5 cl ock cycles l ong, instead o f the minimum length of 4 cl ock cycles . The
time for the arbitration protocol needed during every access results in bus idle time.
ITD08295
Idle%10
M32
17 %
CPU
73 %
PEB 20320
Application Notes
User’s Manual 200 01.2000
Frame Proces sin g
During normal operation the processing of a frame comprises three consecutive parts.
During tran smissi on from ISDN to L AN the frame is first processed fr om the MUNICH3 2,
then from the CPU and finally from the LAN controller.
Figure 98
Frame Proces sin g
Though the CPU is never idle, its part on frame processing is that between the
MUNICH32 and the LAN controller are active. The time to process one frame is the
minimum delay required between frames during continuous transmission.
ITD08296
MUNICH32
CPU
i82596
t
Frame 1 Frame 2
PEB 20320
Application Notes
User’s Manual 201 01.2000
5.2.5 Final Remarks
This appl ication no te shows a desig n example for the MUNICH 32 (PEB 20320). Th ough
the design example is of reduced complexity it gives an idea of how to use the
MUNICH32 in a system. The MUNICH32 is integrated in a 68040 processor system in
conjunction with one more alternate bus master.
To achieve higher data rates the time to process the frames should be minimized. This
includes minimization of bus idle time. The bus arbitration still has big improvement
potentia l becaus e of its m odular s tructure. Add itionall y the exi stence of th e alternate bus
masters results in clocking the bus controller with two different frequencies. This also
results in increased idle time for the bus should therefore be modified. Furthermore
frame processing could be shortened by eliminating the wait states in every bus cycle.
The influ ence of MUNICH3 2 poll acces ses is ex tremely h igh in this ex ample, bec ause of
the bus arbi tration architec ture and the syste m architecture with one bus controller for all
bus masters. But anyway it should always kept in mind, that the bus occupancy during
polling is higher than during transmission. During transmission it decreases rapidly.
No upper layer software is realized in this example so far. For ‘real life’ routing layer 2
and 3 software module(s) have to be integrated.
PEB 20320
Application Notes
User’s Manual 202 01.2000
Figure 99
Integration of Upper Layer Software
ITS08297
Message Descr
MUNICH32
RC Descr
TX Descr
MUNICH32 MUNICH32
DDM DDM
LAN Controller
Message Descr
LAN Controller
TX Descr
LAN Controller
RC Descr
ISDN Route Frame
LAN Route Frame
MROUTE Module
Upper Layer
SoftwareSoftware
Upper Layer
PEB 20320
Application Notes
User’s Manual 203 01.2000
5.2.6 Adaption of the 68040 µP Signals
begin header
This GAL i s used to adap t the 68040 µ-processo r signals to th e MUNICH32. It is used
in a system with a frequency relationship of 1/2 PCLK/SCLK.
end header
begin definition
device gal1 6v8; {Select the device to be Gal16V8}
input bclk = 1,
M32ASQ = 2,
reset = 3,
M32BGACKQ = 4,
int = 5,
ACREQM68 = 6,
RWQ = 7,
clk = 8, {= musclk}
rclk = 9;
feedback (com) DSACKQ = 19;
output (com) TSQ = 18,
RESETQ = 17,
INTQ = 16,
ACREQM32 = 15,
sclk = 14;
statebits sb2 = 13,
sb1 = 12;
state_names idle = 2,
one = 1,
two = 0;
end definition
PEB 20320
Application Notes
User’s Manual 204 01.2000
begin equations
TSQ.OE = /M32BGACKQ;
TSQ = /(/M32ASQ × DSACKQ);
RESETQ = /reset;
INTQ = int;
ACREQM32 = /(/ACREQM68 × reset × /RWQ);
sclk = (/reset × rclk) + (reset × /clk);
end equation s
begin state_diagram tktadaptor (sb2, sb1)
state all:
if (/reset + M32ASQ) then idle
with DSACKQ = 1;
endwith;
state idle:
DSACKQ = 1;
if (/M32ASQ × reset) then one else idle;
state one:
DSACKQ = 1;
go to two;
state two:
DSACKQ = 0;
if M32ASQ then idle else two;
end state_diagram
PEB 20320
Application Notes
User’s Manual 205 01.2000
5.2.7 Schematics
Figure 100
ITS08298
LAN Interface
SERINT.SCH LAN_CONT.SCH
MUBGQ
MUBGOQ
MUBGACKQ
MUBRQ
BGQ
BGACKQ
BRQ
ISDN
EASY320.SCH
SER_INT
MUBGQ
MUBGOQ
MUBGACKQ
MUBRQ
BGQ
BGACKQ
BRQ
Ctrl
A
D
Ctrl
A
D
PEB 20320
Application Notes
User’s Manual 206 01.2000
Figure 101
ITS08299
1P
5
17
4
16
3
15
2
14
1
18
6
19
7
20
8
21
9
13
25
12
24
11
23
10
22
GND 13
2
JP1
GND
CC
V
LIN1
FSQ
LIN2
LOUT1
LOUT2
SYNC
CLK4M
CLK2M
XCLK
ACFA_PRACT
ACFAPRAC.SCH
MUNICH32
MUNICH32.SCH
PCLK3
RTCLK
TRSP
PCLK3
CLK2M
FSCQ
XDI
RDO
TDATA
RDATA
CONNECTOR DB25
Female
PEB 20320
Application Notes
User’s Manual 207 01.2000
Figure 102
ITS08300
J1A 32 A
32
31 31
30 30
29 29
28 28
27 27
26 26
25 25
24 24
23 23
22 22
21 21
20 20
19 19
18 18
17 17
16 16
15 15
14 14
13 13
12 12
11 11
10 10
99
88
77
66
55
44
33
22
11
VG96
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A2
3
4
5
6
7
8
9
11
19
21
29
31
10
12
13
14
15
16
17
18
20
22
23
24
25
26
27
28
30 30
28
27
26
25
24
23
22
20
18
17
16
15
14
13
12
10
31
29
21
19
11
9
8
7
6
5
4
3
2
VG96
65
166
267
368
469
570
671
772
873
974
10 75
11 76
12 77
13 78
14 79
15 80
16 81
17 82
18 83
19 84
20 85
21 86
22 87
23 88
24 89
25 90
26 91
27 92
28 93
29 94
30 95
31
32 D96
J1C
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D0
1
U1
MUNICH32
100 BE0
1BE
96 2BE
94 3BE
91
102 A
A2
3A A
107
4A A
109
5A A
114
6A A
116
7A A
120
8A A
122
9A A
126
10A A
128
11A A
133
12A A
135
13A A
139
14A A
143
15A A
147
16A A
149
17A A
154
18A A
156
19A A
160
20A A
2
21A A
6
22A A
8
23A A
13
24A A
15
25A A
19
26A A
21
27A A
26
28A A
28
29A A
33
30A A
35
31A A
39
32 29
29 27 28
28 25 27
27 20 26
26 18 25
25 14 24
24 12 23
23 722
22 521
21 120
20 159 19
19 155 18
18 153 17
17 148 16
16 146 15
15 142 14
14 138 13
13 134 12
12 132 11
11 127 10
10 125 9
9121 8
8119 7
7115 6
6113 5
5108 4
4106 3
3101 2
299 1
1
0D 0D
95
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D30
31 38
34
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D31
30
90 W,R/R,W
85 ADS/AS
86 DS
75 READY/DSACK
76 BERR
74 B
82 HOLD/BR
79 HLDA/BG
81 PM
80 HLDAO/BGO
66 AR
40 INT/INT
16
MUINTQ
CRSTQ
ADDWSQ
PCSQ5
WRQ
BGACKQ
M32BGQ
LOCKQ
BGQ
TSQ
BCLK
BBQ
VG96
33
134
235
336
437
538
639
740
841
942
10 43
11 44
12 45
13 46
14 47
15 48
16 49
17 50
18 51
19 52
20 53
21 54
22 55
23 56
24 57
25 58
26 59
27 60
28 61
29 62
30 63
31
32 MUSCLK64
J1B
2JP
12
GND
CC
V
MUBGOQ
MUBGQ
RCLK 44
45
RSP
RDATA 46
69
TCLK
TSP 68
TSP 67
Ωk4.7
1RP
89
7 10
6 11
5 12
4 13
3 14
2 15
161
CC
V
MUBGACKQ
U7
OE 11 MUSCLK
CLK
89
Ι7Ι8
7
Ι6
5Ι6
4Ι5
3Ι4
3
Ι2
1Ι2
GAL16V8
12 O8
7O
13
14 O6
SCLK 61
15 O5
16 O4
17 O3
60
RESET 18 O2
O1
19
DSACKQ
56
3
JTEST
JTEST255
JTEST1 54
JTEST0 53
19 1O2O
18 3O
17 4O
16 5O
15 6O
14
13 O7
8O
12
GAL16V8
2
Ι1
2Ι3
4
Ι35
Ι46
Ι5
6Ι7
8
Ι7
Ι9
8
CLK 11
OE
U8 GND
BCLK
M32BGQ
MUBRQ
CC
V
1
R
3.3 kΩ
BRQ
BGACKQ
M32BGQ
PCLK3
TDATA
RDATA
TRSP
RTCLK
GND
CC
V
1
C
100 nF nF100
C
2
nF100
C
3
nF100
C
4
nF100
C
5
nF100
C
6
nF100
C
7
nF100
C
8
nF100
C
9
nF100
C
10
nF100
C
11
nF100
C
12
nF100
C
13
nF100
C
14
ASQ
CRSTQ
MUBGACKQ
INT
PCSQ5
RWQ
TSQ
MUINTQ
GND
CRSTQ
BBQ
LOCKQ
BRQ
BGACKQ
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
PCLK3
BGQ
0CI1
2
3
47
48
49
50
451
CI
CI
CI
CI 65
TEST
73
I/M
GND
PEB 20320
Application Notes
User’s Manual 208 01.2000
Figure 103
ITS08301
VG96
J2A
11
2
23
34
45
56
67
78
89
910
10 11
11 12
12 13
13 14
14 15
15 16
16 17
17 18
18 19
19 20
20 21
21 22
22 23
23 24
24 25
25 26
26 27
27 28
28 29
29 30
30 31
31 32
32
U3
CE
46PCSQ2 22 RD
FRDQ 25FRDQ WR
5INTQ2 AINT
36 ACKNL
2
U2A
74HC04
R
2
1kΩ
CC
V
D1
LED Red
1
3JP
22 33
11
Ωk4.7
3
R
CC
V
18 A
ADR0
1ADR A
19
2ADR A
20
3ADR A
21
0
1
2
3
27
4
34
33
8
RDO COS
RDO
XDI
ROID
XOID
RSIGM
39 XSIGM
40 RCHPY
6
V
CC
R
4
10 kΩ37 XCHPY
AD0 9 D0
1D
101 2D
112 3D
123 4D
134 5D
145 6D
156 7D
167
ACFA
CLK
1
GND
1Ι
22Ι
33Ι
44Ι
55Ι
66Ι
77Ι
88Ι
9
OE
11
U10
GAL16V8
1O 19
18
O2 17
O3 16
O4 15
O5 14
O6 13
O7 12
O8
LOOP
RSTQ
RDO
AD0
AD1
AD2
AD4
AD5
PCSQ2
G0
G1
G2
G4
G5
GXDI
G6
ADR0
ADR1
ADR2
ADR3
30
31
36
37
38
39
40
4
32
28
29
1 3
2
JP4
FSC
CLK2M
CLK4MQ
XCLK
CLK2MQ
XTOM 3
XTOP 44
XDOM 43
XDOP 42
RDIM 31
RDIP 30
XRCLK 41
RRCLK 29
SCLK 28
7
32
35
RFSP
SYP
RES
D2
1N4148 U2B
Green
LED
D3
34
C
15
47 nF
GND
6
RkΩ1
74HC04
1ΩM
R
5
CC
VGND
GXDI
COS
7
AD
AD
AD
AD
AD
AD
AD
XDI
PEB 20320
Application Notes
User’s Manual 209 01.2000
Figure 104
ITS08302
PCSQ2
G0
G1
G2
G4
G5
GXDI
G6
4AD3AD
1AD0AD
96
95
94
93
92
91
90
89
88
87
86
85
84
83
82
81
80
79
78
77
76
75
74
73
72
71
70
69
68
67
66
65
J2C
VG96
AD5
AD6
AD7
6FSC
7FSC
XDIN
30
31 XDIP
RDOP
36
37 RDON
RCLK
38
39 CLK2M
40 CLK2M
4CLK4M
5CLK4M
16 CLK12M
15 CLK16M
32 XCLK
28 XTIN
29 XTIP
U4
FSCQ
FSC
CLK2M
CLK4MQ
XCLK
CLK2MQ
PRACT
pF12
17
C C
18
12 pF
X2
16
CC
19
23
CC20 pF10
22
C
C21
10 pF
33
9
10
12
13
43
11
14
26
3
27
17
CS
XTAL
XTAL
XTAL
XTAL
4
3
2
1
LS
LS
LR
LL
MODE
JATT
SYNC
LS
80
2
1
2.2 Ωk
R
V
CC
LP
COS
JATT
MODE
4AD
2AD1AD0AD
WRQ
PCSQ3
RSTQ
8O 12
7O 13
6O 14
5O 15
4O 16
3O 17
2O 18
19
O1
GAL16V8
U9
11 OE
9Ι8
8Ι7
7Ι6
6Ι5
5Ι4
4Ι3
3Ι2
2Ι1
GND
1CLK
3AD
PCLK3
LOOP
2.2 kΩ
R
15 CC
V
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
GND
CC
V
VG96
J2B
RSTQ
INTQ2
PCSQ4
PCSQ3
PCSQ2
WRQ
FRDQ
XDI
RDO
SYNC
CLK2M
CLK2MQ
CLK4MQ
FSC
FSCQ
XCLK
CLK33_CON
GND
35
41
23
22
SSD
V
V
SSR
SSX
V
V
SSX
47 nF
C
24
DDX
V
V
DDX
DDR
V
V
DDD
18
19
42
34
DD2
V1
25
Cµ47
CC
V
RkΩ60
11
11
60 Ωk
R
nF100
26
C
CC
V
GND
GND
CC
V
D10 D11
V
CC
GND
8
15 Ωk
R
R
kΩ15
7
D8 D9
D5D4
GND
CC
V
D6
V
CC
GND
D7
1
2XL
XL
RL
RL2
1
20
24
44
2
3
8
6
5
5
6
8
3U6
U5
9
1Ωk
R
R
kΩ1
14
F6
SO5K130
GND
1
2
1
2
LOUT1
LIN1
2
1
2
1
GND
SO5K130
F5
13
1Ωk
R
R
kΩ1
12
LOUT2
LIN2
F1
A81_C90X
F3
A81_C90X
A81_C90X
F2
A81_C90X
F4
ZKB_402/512
ZKB_402/512
nF100
31
CC
30
100 nFnF100
29
C
nF100
28
C
GND
CC
V
G0
1G2G
6G
G
G5
4
JATT
SYNC
MODE
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
PCLK3
AD2
F
16 MHz
MHz12
X1 GND
1
10
10
1
PEB 20320
Application Notes
User’s Manual 210 01.2000
Figure 105
ITS08303
14 D0
1D
15 2D
16 3D
17 4D
18 5D
19 6D
20 7D
21 8D
25 9D
26 10D
27 11D
28 12D
29 13D
30 14D
31 15D
32 16D
35 17D
36 18D
37 19D
38 20D
39 21D
40 22D
41 23D
42 24D
43 25D
46 26D
47 27D
48 28D
50 29D
51 30D
52 31D
53
114
0BE
BE1 113
BE 2 112
BE3 109
A108
2
3A 107
4A 106
5A 105
6A 104
7A 103
8A 102
9A 101
10A 97
11A 96
12A 95
13A 94
14A 93
15A 92
16A 91
17A 90
18A 87
19A 85
20A 84
21A 83
22A 82
23A 81
24A 80
25A 79
26A 76
27A 74
28A 73
29A 72
30A 71
31A 70
U
18 1
1
16 1
14 1
12 2
92
72
52
3Y
Y
Y
Y
Y
Y
Y
Y1
2
3
4
1
2
3
4
1A1
1A 2
1A 3
1A 4
2A1
2A2
2A3
2A4
U
CLK33
TSP_OUT
PCLK3
TCLK_OUT
CLK33_CON
74HCT244
1G
2G 19
1
17
15
13
PHI
833 MHz
GND
TCLK_IN
TSP_IN
OSZI
11
8
6
4
2
Data
CC
V
124
65
129
130
9
123
118
69
ADS
LE/BE
BS
RDY
HOLD
HLDA
RESET
CLK2
16
3PORT
125 INT/INT
119 CA
3.3 kΩGND
V
CC
2.7 kΩ
82596DX
RDTQ
ADSQ
HOLD
RLDA
L_RESET
PORTQ
CA
MUINTQ
GND
57
RTS
CTS
TXC 64
TXD 54
RXC 59
RXD 60
CRS 63
CDT 61
62
V
CC
115
BREQ GND
Resistor
R
126
120
58
LOCK
W/R
LPBK
16 1
2
15 314 413 512 611 710 89
RP1
4.7 kΩ
RDTQ
MU_BGOQ
L_LOCKQ
CPURSTQ
LAN_W_RQ
ADSQ HOLD
Ωk2.7
2RP
9 8
10 7
11 6
12 5
13 4
14 3
15 2
1
16
GND GND
12
3
4
5
6
7
8
9
4.7 Ωk
SER_INT
L_LOCKQ
LAN_W_RQ
ADDR
BE
RAPACK
V
CC
CC
V
PEB 20320
Application Notes
User’s Manual 211 01.2000
Figure 106
ITS08310
8O 12
7O 13
6O 14
5O 15
4O 16
3O 17
2O 18
19
O1
GAL16V8A
RESET
11 OE
9Ι8
8Ι7
7Ι6
6Ι5
5Ι4
4Ι3
3Ι2
2Ι1
GND
1CLK
MUCLK
CPURSTQ
L_RESET
PORTQ
CPURSTQ
MUCLK
CLK
1
GND
1Ι
22Ι
33Ι
44Ι
55Ι
66Ι
77Ι
88Ι
9
OE
11
Port
GAL16V8A
1O 19
18
O2 17
O3 16
O4 15
O5 14
O6 13
O7 12
O8
CA
M32_ARQ
DTOEQ
LAN_CSQ
R_WQ
M32_ARQ
CLK33
GND
CLK33
HLDAIN
TSQ
R_WQ
8O 12
7O 13
6O 14
5O 15
4O 16
3O 17
2O 18
19
O1
GAL16V8A
Signal
11 OE
9Ι8
8Ι7
7Ι6
6Ι5
5Ι4
4Ι3
3Ι2
2Ι1
GND
1CLK
TAQ RDYQ
ADSQ
LAN_W_RQ
HOLD
MU_BRQ BRQ
ML_BGQ
CLK
1
GND
1Ι
22Ι
33Ι
44Ι
55Ι
66Ι
77Ι
88Ι
9
OE
11
Arbiter
GAL16V8A
1O 19
18
O2 17
O3 16
O4 15
O5 14
O6 13
O7 12
O8
BGACKQ
HLDAIN
MUCLK
CLK33
2
MU_BGACKQ
CPURSTQ
MU_BGQ
M32_CSQ
A4
ML_BGQ
MU_BGACKQ
LAN_CSQ
SIZ1
8O 12
7O 13
6O 14
5O 15
4O 16
3O 17
2O 18
19
O1
GAL16V8A
Address
11 OE
9Ι8
8Ι7
7Ι6
6Ι5
5Ι4
4Ι3
3Ι2
2Ι1
GND
1CLK
A0
PCSQ5 A1
SIZ0
BE BEQ0
BEQ1
BEQ2
BEQ3
PEB 20320
Application Notes
User’s Manual 212 01.2000
Figure 107
ITS08311
J1C 65 D0
1
2D66
3D67
4D68
5D69
6D70
7D71
8D72
9D73
10 D74
11 D75
12 D76
13 D77
14 D78
15 D79
16 D80
17 D81
18 D82
19 D83
20 D84
21 D85
22 D86
23 D87
24 D88
25 D89
26 D90
27 D91
28 D92
29 D93
30 D94
31 D95
32 D96 31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
Data
VG96 VG96
Address
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
10A
J1A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
1
VG96
64
32 63
31 62
30 61
29 60
28 59
27 58
26 57
25 56
24 55
23 54
22 53
21 52
20 51
19 50
18 49
17 48
16 47
15 46
14 45
13 44
12 43
11 42
10 41
940
839
738
637
536
435
334
2
133
J1B
PCLK3
DTOEQ
TAQ
MUINTQ0
CPURSTQ
MUINTQ
GND
CC
V
PCSQ5
W_RQ
BGACKQ
ML_BGQ
LOCKQ
BGQ_68
TSQ
BCLK
BBQ
MUCLK
PEB 20320
Application Notes
User’s Manual 213 01.2000
Figure 108
ITS08312
17 TXD
TXD
TXCQ TXC
16
RTSQ TEN
15
6CRS
CRSQ 8RXC
RXCQ
RXD RXD
9
CDTQ CDT
7ENETV1
1
2NOOR
CAP
C
LPBKQ 3LPBK/WDTD
SERINT CLSN 12
11
CLSN
RCV 4
RCV 5
18
TRMT 19
TRMT
1
2
3
CD+
CD-
RX+
TX-
TX+
RX-
6
5
4
UU
82C50TAD EM2
GND GND
13
14
Y
C
30 pF pF30
C
20 MHz
CDS 20
18
RXI 17
TXO
JP
13
2GND
16
11
CC
V
JUMPER3X1
HBE
DM
C
0.01µF1MΩ
R
EE
V
GND
12
O4
R
150 Ω
D
LED Yellow
U
T21
5B
4A2
A1
3
9RIN
11 REXT/CEXT
R
40 kΩ
10 CEXT
C
k105
CC
V
X1
X2
Q6
1
QLED Green
D
D
LED Red
Q6
1
Q
k105
CCEXT
10
RREXT/CEXT
11
RIN
9
3A1
A2
4B
5
T21
U
R
150 Ω
R
150 Ω
UA
CC
V
40 kΩ
V
CC
GND
12
GND
GND
J
BNC
R
Ω78 78 Ω
R240 Ω
R240 Ω
R
PEB 20320
Application Notes
User’s Manual 214 01.2000
5.3 Memo ry Bus Occupanc y for a S ing le MUNICH32
The MU NICH32 may be used in d ifferent sys tem architec tures depend ing mainly on how
the data buffers are shared between the interacting bus masters. In the following the
memory bus occupancy is calculated for a system, where the MUNICH32 is directly
couple d with a 32 -bit CPU (compati ble to eithe r Motorola 68020 or Intel 386) sharin g one
commo n l oca l C PU bus and tran sl ated via an a ppro pria t e s yste m bus contro lle r sharing
the syste m mem ory as well . This exa mple sy stem looks ve ry simila r to the one depicte d
in the Figure 7 and Figure 9 of Chapter 1. In this case it is easier to estimate the
behavior of the complete system.
In addition to that, the following assumptions are made about the communication
parameters:
–HDLC operating mode
–the MUNICH is clocked with SCLK = 16 MHz
–the bus arb itratio n time is est imate d to be a bout 4 e xtra cl ock cyc les (SCL K) for eve ry
10 MUNICH32 memory accesses (typical is 10 to 16)
–the data buffer size allocated in the data buffer pool is 32 bytes for transmit and
receive descri pto rs
–a full duplex connection with up to 32 ×64 Kbit/s channels and heavy traffic load
(shared flags)
–the data size per HDLC frame is defined to be without the shared flag and the two CRC
bytes
–when the da ta size exc eeds 32 bytes, m ore than one des criptor is ne eded for a singl e
frame
–an interrupt information is generated for every descriptor.
The MUNICH32 needs the following 32-bit memory accesses (read or write):
Receiv e: read descri pto r → 3
write current descriptor address → 1
write status → 1
write interrupt → 1
write data (size) → accesses size
11
12
13
14
25
::
PEB 20320
Application Notes
User’s Manual 215 01.2000
Transmit: read descriptor → 3
write current descriptor address → 1
write interrupt → 1
read data (size) → accesses size
11
12
13
14
25
::
The acc umula ted ac cess time for a si ngle M UNIC H32 ch annel, dep endin g on the actua l
frame size, is then related to the serial transfer time on a PCM system:
(3 + size) ×125 µs.
The follow ing two diag rams illustrat e the overall res ults for two diff erent ranges an d their
corresponding resolution. As you can see, for frame size greater than 32 bytes the time
needed for MUNICH32 memory accesses drops below 5%. That means in a simple
communication subsystem (e.g. Primary Access Board) the CPU performance is also
reduced by 5% o nly and it is th erefore no t necess ary to u se a co mplex mul tiport memory
approach to reach a significant overall performance gain.
Figure 109
Frame Size 1 to 512
ITD04696
01
5
10
15
20
25
32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512
%
Number of Data Bytes
Ch=32
Ch=30
Ch= 1
Memory Bus Occuppancy
PEB 20320
Application Notes
User’s Manual 216 01.2000
Figure 110
Frame Size 1 to 32
0
1
5
10
15
20
25
%
29 30 31 3227 282 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Memory Bus Occuppancy
Number of Data Bytes
ITD04697
Ch= 1
Ch=30
Ch=32
PEB 20320
Application Notes
User’s Manual 217 01.2000
5.3.1 Bus Occupancy Calculations
As described in the previous section, the MUNICH32 in a steady state condition
consumes approximately 5% of the system bus bandwidth. Based on the conditions
previ ously desc ribed, a se t of equatio ns can be u sed to des cribe the MU NICH32 sys tem
bus behavior. Other MUNICH32 systems can be evaluated using these equations. The
Bus occu pa ncy is defined as the rati o of t he time require d for m em ory ac ce ss es for th at
data to the time used to send the data. The two equations are defines as follows:
Time used for memory accesses:
= Number of received bits plus transmitted bits multiplied by the time required to
transfer this
informati on to/f rom memo ry.
={([6+(1+m)] ×rc) + (5 + (1 + m)] ×tc)} ×(1 + 1/ba)×NC ×sclk
6 for receive descriptor access
5 for transmit descriptor access
(1 + m) for data access where m is the largest integer smaller (n–1)/4
(n is the number of transmitted data bytes).
rc is the number of receive channels.
tc is the number of transm it cha nne ls .
(1 + 1/ba) is the bus arbitration time
sclk is the system clock (61 ns for 16.384 MHz)
NC is the numbe r of m emory c locks p er bus opera tion (0 ws = 4, 1WS = 5, etc .).
Time u s ed t o send t h e dat a is t he num b er o f t r ansm it t e d bit s p e r t im e sl ot m ult ip l ie d by
the frame time:
= ((4 + n) × 8/abtc) × 125 µs
4 because shared flags are not used + 2 byte CRC
n is the number of octets to transmit
abtc = assigned bits to channel
e.g. a channel with one time slot of 1 bit would require 8/1 = 8 time slots to
transmit a single octet.
From the previous example, the variables are assigned the following values:
Variable n m rc tc (1 + 1/ba) sclk NC abtc
Value 32 bytes 7 32 32 1.1 61 ns 4 8
PEB 20320
Application Notes
User’s Manual 218 01.2000
Applying these values to the equations yields the following:
Time used to access memory
= {([6 + (1 + 7)] × 32) + ([5 + (1 + 7)] × 32)} × (1.1) × 4 × 61 ns
= {(14 × 32) + (13 × 32)} × 1.1 × 244 ns
= {864} × 268.4 ns
= 231.9 µs.
Time used to send data
= ((4 + 32) × 8/8) × 125 µs.
= 36 × 125 µs.
= 4500 µs.
Bus occupancy = 231.9 µs/4500 µs = 5.1%
When the p acket size i s much large r (256 bytes or la rger), the bus oc cupancy decrea ses
to less than 4%. Conversely, sending very small frames (4 bytes), causes bus
occupancy to increase to over 11%. This is primarily due to the increased descriptor
processing pe r packet.
5.3.2 Bus Occupancy for Idle Tx Channels
The pr evio us dis cuss ion s hows b us oc cupa ncy to be v ery lo w, ev en w hen a MUNI CH32
is processing 32 channels of receive and transmit data. There is another system
consideration of bus occupancy that must be examined. When a MUNICH32 channel
has no data required for transmit, the channel must be temporarily (or permanently)
stopped. There are several methods that may be used to stop the transmission.
1. The first method involves executing a channel command with TH = 1 (reactivation of
the channel requires a new channel command with TH = 0). This method places the
transmit channel on hold and prevents any further accesses of the memory for this
channel.
2. A second method is based on statistical knowledge of the frequency of transmitted
frames. If frames are transmitted without shared flags and if the average number of
interframe time fill c haracters can b e determined, the MUNICH32 c an be program med
to suppress poll sequences. By setting FNUM in the Tx descriptor to a value (n)
greater than 0, the MUNICH32 will transmit n + 1 idle characters after the end of the
current frame. During this period of interframe time fill, the MUNICH32 will not poll the
Tx descriptor. As an example, if it is determined that 5 idle characters typically occur
between frames, FNUM can be set to 4. At the end of the current frame, 5 idle
characters will be transmitted (625 µs. on a DS0 channel) before the next frame is
transmitted and no polls of the Tx descriptor will occur during that time.
PEB 20320
Application Notes
User’s Manual 219 01.2000
3. The final metho d is to set the HOLD bit in the Tx descrip tor. When the HOL D bit in the
Tx descriptor i s s et, the MU NIC H3 2 c hec k s t he s ta tus of the this bit f or e ach ti me slot
assigned to this channel. In this way, if the bit has been cleared, the MUNICH32 will
immedia tely resume tra nsmission. Althou gh this method is simple r (in concept) for the
software design, it causes the MUNICH32 to consume higher than normal bus
bandwidth. For this reason, this is the least desirable of the three methods. In the
previous example discussed, if all 32 channels were holding on the Tx descriptors,
bus occupancy might rise as high as 17%. The reason bus occupancy rises this
dramatically is due to the bus access once per time slot rather than once every four
time slot s (typical).
PEB 20320
Application Hints
User’s Manual 220 01.2000
6 Application Hints
6.1 Frequency Adapti on in an Intel 368 Common Bus Syste m
If yo u us e t he i38 6 as host proces so r w ith th e M U NIC H3 2 i n a co mm on bus s ys tem yo u
have to adapt the different frequencies of the devices. The MUNICH32 works e.g. with
a fixed frequency of 16.384 MHz in CEPT 32 channel PCM highway format. The i386
works with frequencies from 16 up to more than 50 MHz. If you compare the timing
diagrams you will see that a few glue logic is necessary to adapt the MUNICH32 to the
i386 timing.
A possible adaption of the different frequencies is described below. For an example we
use an i38 6 with a freq uen cy of 16. 384 MHz . The MUN ICH32 is co nfigure d in the CEPT
32 channel PCM highway format with a SCLK of 16.384 MHz. The SCLK signal is build
by dividing the 32.768 MHz CLK2 signal of the i386. That means that both clocks are
synchronous. This is not necessary in general but selected in our example. The bus
controller generates e.g. one wait state for the memory access. The falling edge of the
ADS signal marks the beginning of a bus cycle which is completed with the sampled
READY sign al. A general bus c ontroller shou ld not see a dif ference between the two bus
masters, so we have to delay the falling edge of the MUNICH32 ADS signal to that
moment as the i386 would generate its ADS to get the READY signal at the same time.
In the picture below you can see the relationship and the adaption of both timings as
specified in our example. A second picture shows the adaption in an i386 24.576 MHz
system. Again the clocks are synchronous.
PEB 20320
Application Hints
User’s Manual 221 01.2000
Figure 111
ITD04556
SCLK
ADS
READY
CLK
CLK2
ADS
READY
S1 S2
MUNICH32
SCLK=16.384 MHz
T1
Delay
i386, 16.384
=>CLK2=2xSCLK
MHz
T1 T2T2 T1
PEB 20320
Application Hints
User’s Manual 222 01.2000
Figure 112
ITD04557
SCLK
ADS
READY
CLK
CLK2
ADS
READY
S1 S2
MUNICH32
SCLK=16.384 MHz
T1
Delay
i386, 24.576
=>CLK2=3xSCLK
MHz
T1 T1 T1 T2 T2 T1
PEB 20320
Application Hints
User’s Manual 223 01.2000
6.2 MUNICH32 Memory Space Requirement
Implementation independent:
–Start Address 4 byte
–Control & Configuration Sect ion 908 byte
–Tx Descriptor Size 12 byte
–Rc Descriptor Size 16 by te
Implementation dependent:
–Interrupt Queue Size 64 byte < Interrupt Queue Size < 16384 byte
–Data Buffer Size Data Buffer Size
–Allocation of Tx and Rc descriptors per channel
In general the memory space requirement may be calculated the following way:
Start Address
+ Size of Control & Configuration Section
+ Interrupt Queue Size
+ number of channels × [number of Tx Descriptors × (Tx Descripto r Size + Data Bu ffer Size)] +
number of channels × [number of Rc Descriptors × (Rc Desc riptor Size + Data Buffer Size)]
–––––––––––––––––––––––––––––––––––––––––––––
= T otal MUNICH32 Mem ory Spac e Requirement
Example:
The MUNICH32 is used in a 31 channel ISDN Primary Access application, that means
that 31 full duplex channels are active. The LAPD protocol is implemented. In this case
a window size of 7 is specified, that means that 7 Rc Descriptors and in transmit direction
7 Tx Descripto rs mu st be av ail ab le for eac h cha nn el. The Dat a Buffer Size is se t to 260
byte according to the LAPD specification.
Summary:
–31 channels;
–Interrupt Queue Size = 1024 byte;
–7 Tx and 7 Rc Descriptors;
–Data Buffer Size = 260 byte;
In our example a memory space of 120 kbytes is required.
PEB 20320
Application Hints
User’s Manual 224 01.2000
6.3 Serial Interface to different PCM Systems
The serial interface of the MUNICH32 is very general and comprises standard clock,
PCM fra me synch ronizatio n and da ta signa ls, which are independe nt for bo th directi ons.
The following description explains typical applications integrating the MUNICH32 into
2.048 Mb ps PCM syste ms, lik e SIEM ENS System Inte rfac e fo r Primary Acce ss and the
MITEL ST BUS. In these systems the receive and transmit clocks are identical. The
general timing is shown in Figure 113 (see also Chapter 2.1).
Figure 113
The R SP pulse is s hifted by o ne clock period agai nst the TSP pulse. The main task using
this tim ing fo r different PCM s ystems is to adapt th e TSP an d RSP puls es ap propria tely,
as described below.
6.3.1 MUNICH32 for SIEMENS Primary Access Interface
The SIEMENS de vice s for the Primary Access In terface is the Frame a nd Line Inte rface
Component (FALC54 ). Th is dev ic e c an di rec tly be co nne cte d to the MUN IC H32 w i tho ut
any additi onal glu e logic. In comb ination wit h the MUNICH32 this applica tion is the most
effective way to build a powerful and flexible Primary Access Interface, especially
supporting different combined B channel paths over long distances (LAN-WAN
Internetworking). The following block diagram illustrates how easy it is to integrate the
MUNICH32 into a Primary Access application based on SIEMENS devices.
ITD04694
Time-Slot 0
Time-Slot 0
RCLK=TCLK
TSP
RSP
TDATA
RDATA
PEB 20320
Application Hints
User’s Manual 225 01.2000
Figure 114
The adapti on of the TSP and R SP pulses is solved by means of shifting th e receive da ta
and transmit data in the FALC54 device appropriately. In this case the TSP and RSP
synch roniza tion puls es a re als o id entica l. The F ALC54 devi ce c ontain s sp ecial regis te rs
to cont rol the bit shift o f th e serial bit s trea ms a t the syste m in terfa ce (s ee FALC5 4 Da ta
Sheet). With the following register programming the bit shift selected is T = 509 for the
MUNICH32 transmit data and T = –1 for the receive data respectively. The
programming is as follows:
XDI: XC1.XTO = 3DH=> X = 494 => T = 509
XC0.XCO = 06H
RDO: RC1.RTO = 00H=> X = 5 => T = –1
RC0.RCO = 05H
ITS07370
TCLK
TSP
TDATA
RDATA
RSP
RCLK
XDI
RDO
CLK8MCLKX
MUNICH32
PEB20320 2254PEB
FALC54
SCLKX
SYPXQ
SCLKR
SYPRQ
FSCFSCQ
PEB 20320
Application Hints
User’s Manual 226 01.2000
The timi ng in princi ple is dep icted i n the followin g diagram . Without all details of a typical
electric al timin g it il lustra tes how t he d ifferen t signals from M UNICH32 , an d FALC54 a re
mapped in such a Primary Access system.
Figure 115
ITD08282
FSC=TSP=RSP
CLKX=RCLK=TCLK
TDATA
=XDI
RDATA
=RDO
(T=509)
(T=-1)
=:Invalid area
Channel 0, Bit 0 (Least Significant Bit)
:
=
PEB 20320
Application Hints
User’s Manual 227 01.2000
6.3.2 MUNICH32 in Systems with MITEL ST BUS
A few more effort is necessary to integrate the MUNICH32 into a ST BUS system from
MITEL. The basic a ssumpti on made here is that the clock m aster is the ST BUS s ystem.
That means all signals derived from the ST BUS need to be adapted to match the
MUNICH32 timing requirements. First of all the clock signal C2 must be inverted before
it can be used as the MUNICH32 clocks (TCLK = RCLK = C2). The next step is the
generation of the TSP and RSP pulses out of the F0 signal, which is the ST BUS frame
synch roniza tion si gnal. The RSP pulse c an be deri ved from the F0 si gna l by mea ns of a
simple D-Flip-Flop clocked with C2, as depicted in the following Figure 116. Due to the
necessary phase relationship between the serial data streams and their corresponding
TSP, RSP and F0 pulses, the effort to generate the TSP pulse is much higher than for
RSP.
Figure 116
ITS04692
TCLK
TSP
TDATA
RDATA
RSP
RCLK
ST-BUS
STi
STo
MUNICH32
PEB 20320
C2 F0
&
Q
QDRES
8-Bit
Counter
D
Q
Q
System Clock Adaption
Decode
’254’
PEB 20320
Application Hints
User’s Manual 228 01.2000
The TSP pu lse must b e derived from the F0 signa l with a phase s hift by 2 55 clock cycles
to be at t he right position. The corresponding timing is illu strated in the following diagram.
Figure 117
ITD04693
C2
F0
TSP
RCLK=TCLK=C2
TDATA
=STi
RDATA
=STo
=:Invalid area
Channel 0, Bit 0 (Least Significant Bit)
:
=
Derived from F0 and synchronized by means of C2
*)
RSP
*)
*)
PEB 20320
Electrical Characteristics
User’s Manual 229 01.2000
7 Electrical Characteristics
Note: All specifications are for V3.4 unless otherwise specified. Version numbers are
identifi ed in the Inte rrup t Inform ati on bits VN(3: 1):
these bits are ‘0000’ for version 1.1
‘0001’ for version 2.1
‘0010’ for version 2.2
‘0100’ for version 3.2
‘0110’ for version 3.4
7.1 Absolute Maximum Ratings
Note: Stresses above those listed here may cause permanent damage to the device.
Exposure to absolute maximum rating conditions for extended periods may affect
device reliability.
Table 12
Parameter Symbol Limit Values Unit
min. max.
Ambient tem per ature under bia s: PEB
PEF TA
TA
0
– 40 70
85 °C
Storage temperature Tstg – 65 125 °C
Voltage at any pin with respect to ground VS– 0.4 VDD + 0.4 V
PEB 20320
Electrical Characteristics
User’s Manual 230 01.2000
7.2 D C Characteristics
Note: The listed characteristics are ensured over the operating range of the integrated
circuit. Typical characteristics specify mean values expected over the production
spread. If not otherwise specified, typical characteristics apply at TA=25°C and
the given supply voltage.
Table 13
TA = 0 to + 70 °C; VDD = 5 V ± 5%, VSS = 0 V
Parameter Symbol Limit Values Unit Test Condition
min. max.
L-input voltage VIL –0.4 0.8 V –
H-input voltage VIH 2.0 VDD + 0.4 V –
L-out put vol tag e VQL –0.45 V IQL = 7 mA
(pin TDATA)
IQL = 2 mA
(all others)
H-output voltage
H-output voltage
VQH
VQH
VDD –0.5
2.4
–V
V
IQH = – 2 mA
(pin HOLD/BR)
IQH = – 100 µA
(all others)
IQH = – 400 µA
Power
supply
current
operational ICC –< 100 mA VDD = 5 V
inputs at 0 V/VDD,
no outputs loads
power down
(no clocks ) ICC –< 2 mA
Input leakage current
Output lea kage curre nt ILI
ILQ
–10 µA0 V < VIN < VDD to 0 V
0 V < VOUT < VDD to 0 V
PEB 20320
Electrical Characteristics
User’s Manual 231 01.2000
7.3 Capacitances
7.4 AC Characteristics
TA = 0 to + 70 °C; VDD = 5 V ± 5%
Inputs are driven to 2.4 V for a logical ‘1’ and to 0.4 V for a logical ‘0’. Timing
measurements are made at 2.0 V for a logical ‘1’ and at 0.8 V for a logical ‘0’.
The AC testing input/output waveforms are shown below.
Figure 118
Input/Output Waveform for AC Tests
Table 14
TA = 25 °C; VDD = 5 V ± 5%, VSS = 0 V
Parameter Symbol Limit Values Unit Test Condition
min. max.
Input capacitance CIN 510pF–
Output capacitance COUT 815pF–
I/O-capacitance CIO 10 20 pF –
ITS00621
= 150
Load
C
Test
Under
Device
0.45
2.4 2.0
0.80.8
2.0 Test Points
pF
PEB 20320
Electrical Characteristics
User’s Manual 232 01.2000
7.5 Microprocessor Interface Intel Bus Mode
Figure 119
Timing Diagram Intel Bus Mode
ITD03510
1
SCLK
A31-A2
BE(3:0),
ADS
READY
2
D31-D0
3 3 45
8
(read cycle)
(write cycle)
D31-D0
BERR
S1 S2 S1
10
9
7
6
PCHK
[DP(3:0)]
[DP(3:0)]
11 11
PEB 20320
Electrical Characteristics
User’s Manual 233 01.2000
Figure 120
Bus Arbitration Timing Diagram Intel Bus Mode
Intel Bus Timing
Table 15
No. Parameter Limit Values Unit
min. max.
1 Address, valid delay –20 ns
2 BE, INT, W/R valid delay –20 ns
3ADS
valid delay –20 ns
4 READY setup time 10 –ns
5 READY hold time 5 –ns
6 BERR setup time 10 –ns
7 BERR hold time 5 –ns
8 Data valid delay (write) –35 ns
9 Data setup time (read) 5 –ns
10 Data hold time (read) 8 –ns
ITD03511
12 12
13 13
14 15
16 17
High Z High Z
SCLK
HOLD
HLDAO
HLDA
Microprocessor
Interface
11
PCHK
PEB 20320
Electrical Characteristics
User’s Manual 234 01.2000
11 Parity check valid delay –50 ns
12 HOLD valid delay –20 ns
13 HLDAO valid dela y –20 ns
14 HLDA setup time 10 –ns
15 HLD A hol d time 10 –ns
16 Microprocessor Interface (MI) driven
after HLDA set 2 SCLK cycl es ––
17 MI tristated after bus accesses –40 ns
Table 15
No. Paramet er Limit Values Unit
min. max.
PEB 20320
Electrical Characteristics
User’s Manual 235 01.2000
7.6 Microprocessor Interface Motorola Bus Mode
Figure 121
Timing Diagram Motorola Bus Mode
ITD03513
18
20
SCLK
A31-A2
INT, BE (3:0), R/W
AS
DSACK
D31-D0
19 21 21
23
22
24 25
(read cycle)
(write cycle)
D31-D0
BERR
DS
T1 T2 T3 T4 T1
28
29
19
26
27
PEB 20320
Electrical Characteristics
User’s Manual 236 01.2000
Figure 122
Bus Arbitration Timing Motorola Bus Mode
Motorola Bus Timing
Table 16
No. Parameter Limit Values Unit
min. max.
18 Address, BE , INT, R/W valid delay –20 ns
19 AS, DS asserted after clock low –20 ns
20 AS, DS negated after clock low –20 ns
21 DSACK, BERR setup time to clock low 5 –ns
22 Data read setup time to clock low 5 –ns
23 Data read hold time to clock low 8 –ns
ITD03514
30
33
32
33
SCLK
BR
BG
BGACK
Microprocessor
Interface
30
31
35
36
34
BGO
SCLK
BR
BG
BGO
36 36
PEB 20320
Electrical Characteristics
User’s Manual 237 01.2000
24 Data write valid delay –35 ns
25 Data write hold from clock high –35 ns
26 Address valid to AS high 10 –ns
27 Data valid to DS low 10 –ns
28 DS high to data invalid 5 –ns
29 AS high to address invalid 10 –ns
30 BR valid delay –25 ns
31 BG setup time to clock high 5 –ns
32 BG hold time after BGACK 10 –ns
33 BGACK valid delay –25 ns
34 Microprocessor Interface driven after BGACK
asserted 1 SCLK
cycle ––
35 Clock high to Microprocessor Interface tristated –40 ns
36 BGO valid delay from clock high –40 ns
1) Newly specified for V2.1 and V2.2. Not specified in Data Sheet 08.93.
Table 16
No. Parameter Limit Values Unit
min. max.
PEB 20320
Electrical Characteristics
User’s Manual 238 01.2000
Serial Interface Timing
Figure 123
Table 17
No. Parameter Limit Values Unit
min. max.
37 Receive strobe guard time 10 –ns
38 Receive strobe se tup 5 –ns
39 Receive strobe hold 5 –ns
40 Receive data setup 5 –ns
41 Receive data hold 5 –ns
RSP
RDATA
3937
42
38
43
40 41
RCLK
TCLK
48
47
50
45
49
44 46
TDATA
TSP
ITD03515
PEB 20320
Electrical Characteristics
User’s Manual 239 01.2000
Note: 1. The frequency on the serial line must be smaller or equal to
1/8th of the frequency on the µP bus for 1.536 MHz, 1.544 MHz, 2.048 MHz
1/4th of the frequency on the µP bus for 4.096 MHz.
2. For complete internal or complete external loop t42 an d t49 must be greater or
equal to 3 times t51.
Clock Input Timing
Figure 124
Clock Timing
42 Receive clock high width 60 –ns
43 Receive clock low width 60 –ns
44 Transmit strobe guard time 20 –ns
45 Transmit strobe setup 5 –ns
46 Transmit strobe hold 5 –ns
47 T ransmit data delay –40 ns
48 Transmit clock to high impedance –50 ns
49 T ransmit clock high width 60 –ns
50 Transmit clock low width 60 –ns
Table 17 (co nt’d)
No. Parameter Limit Values Unit
min. max.
5352
SCLK
ITD03516
51
PEB 20320
Electrical Characteristics
User’s Manual 240 01.2000
Note: If fT is the frequ enc y o f the c lo ck TC LK, fR th e fre quency of the c loc k R CL K and fS
the frequency of the clock SCLK the equations
7.996 × max (fT, fR) ≤ fS ≤ 16.667 MHZ for CEPT, T1, E1 PCM mode
and
3.998 × max (fT, fR) ≤ fS ≤ 16. 667 MHZ for 4.096 MHz PCM mode
describe the allowed range of frequencies for fS.
System Interface Timing
Figure 125
After power up a logical ‘1’ at the reset pin of the MUNICH V3.4 sets the device into a
reset st ate where the comp lete m icropr oce ssor bus interfa ce is trista ted and the in ternal
reset sequence is started.
Table 18
No. Parameter Limit Values Unit
min. max
51 Cycle period 50 –ns
52 Clock l ow time 25 –ns
53 Clock high time 25 –ns
Table 19
No. Parameter Limit Values Unit
min. max.
55 Reset to first a c tion request delay 12 S CLK c y cles ––
56 AR# pulse width 2 SCLK cycles 5 SCLK cycles –
57 Reset pulse width 2 SCLK cycles ––
57
RESET
AR
56
ITT10668
55
after reset
request AR
first action
PEB 20320
Electrical Characteristics
User’s Manual 241 01.2000
The traili ng edge of the res et starts the last part of the in ternal rese t sequence and takes
about 12 SCLK cycles. It is not allowed to give an action request (AR) during these first
12 SCLK cycles after the trailing edge of signal RESET.
JTAG-Boundary Scan Timing
Figure 126
JTAG-Boundary Scan Timing
Table 20
Intel Bus Timing
No. P ar am eter Limit Values Unit
min. max.
58 JTEST0 (TCK) period 166 inf –
59 JTE ST0 (TCK) high time 80 ––
60 JTEST0 (TCK) low time 80 ––
61 JTEST1 (TMS) setup time 15 ––
62 JTEST1 (TMS) hold time 10 ––
63 JTE ST2 (TDI) setup time 15 ––
64 JTEST2 (TDI) hold time 15 ––
65 JTEST3 (TDO) valid delay 30 ––
ITD03512
JTEST0 (TCK)
JTEST1 (TMS)
JTEST2 (TDI)
JTEST3 (TDO)
65
62
61
59 60
63 64
58
PEB 20320
Package Outlines
User’s Manual 242 01.2000
8 Package Outlines
GPM05247
P-MQFP-160-1
(Plastic Metric Quad Flat Package)
Sorts of Packing
Package outlines for tubes, trays etc. are contained in our
Data Book “Package Information”.Dimensions in mm
SMD = Surface Mounted Device
PEB 20320
Appendix
User’s Manual 243 01.2000
9 Appendix
9.1 Source Code Extract MUNICH32
The MUNI CH32 code extract is taken from the low level device driver for the MUNICH32,
which is written in ‘C’. This ex tract gives yo u a brief impression how a MUN ICH32 devic e
driver co uld be programmed.
The munich control configuration (munichCtrlCfg) is a structure which consists of the
following substructures:
Action Spec ifi ca tio n actionSpec
Interrupt Queue Specification intQueueSpec
Time-Slot Assignment timeSlot[ ]
Channel Specification channelSpec[ ]
Munich Receive D escriptor Pointer currRcDescrAd dr[ ]
Munich Tran smit De scriptor Pointer currTxDe scrAddr[ ]
These sub struct ures mainl y consi st of bit fields . The use of bit fie lds does not pro duce a
speed optimized but a highly readable code, in our case to demonstrate the
programming of the MUNICH32 very cle arly.
The structures are directly memory mapped to the MUNICH32 structures and listed
below.
In this sh ort example we select the CEPT-32 PCM highway format and the HDLC mode.
All time-slots are assigned to channel number 0. HDLC frames are send via channel0.
There are two functions: InitChannel0AndSendFirstFrame()
TxHdlcFrame().
The function InitChannel0AndSendFirstFrame() comprises the following initialization
tasks:
–the MUNICH32 is configured for the CEPT32 channel format
–the interrupt queue is initialized and assigned
–each time-slot consists of 8 bit and all time-slots are assigned to channel 0
–the transmit outputs and the receive inputs are active
–here nine transmit buffers are assigned to channel0
–idle code flags.
PEB 20320
Appendix
User’s Manual 244 01.2000
The second part of the function prepares the device to send the first HDLC frame:
–the linked list of frames to be send is registered
–in receive direction a linked list of 10 receive descriptors with 32 bytes data each is
prepared and installed.
–the macro MUNICH32_ACTION_REQUEST() ‘generates’ an activati on request pulse
to the MUNICH32
–the device reads the initialization data and transmits the first transmit frame
The MUNICH32 then polls the hold bit of last transmit descriptor until this bit is cleared.
If the hold bit is cleared the device sends the next data until it finds the next hold bit.
The function TxHdlcFrame connects the transmit descriptor of the next frame with the
last transmit descriptor of the last send frame and clears the hold bit; the next frame is
send.
PEB 20320
Appendix
User’s Manual 245 01.2000
9.2 Source Code
…
/*--------------------------------------------------------------------------
- MUNICH32 Transmit Descriptor Structure -
--------------------------------------------------------------------------
*/
typedef struct munichTxDescr
{
unsigned fnum : 11;
unsigned csm : 1;
unsigned : 3;
unsigned v110 : 1;
unsigned no : 13;
unsigned hi : 1;
unsigned hold : 1;
unsigned fe : 1;
WORD8 _ptr data;
struct munichTxDescr _ptr next;
}
MUNICH_TRANSMIT_DESCRIPTOR;
typedef MUNICH_TRANSMIT_DESCRIPTOR _ptr MUNICH_TX_DESCR_PTR
/*--------------------------------------------------------------------------
- MUNICH32 Receiv e Des cripto r Structu re -
--------------------------------------------------------------------------
*/
typedef struct munichRcDescr
{
unsigned : 16;
unsigned no : 13;
unsigned hi : 1;
unsigned hold : 1;
unsigned : 1;
unsigned : 8;
unsigned status : 8;
unsigned bno : 13;
unsigned : 1;
unsigned c : 1;
unsigned fe : 1;
WORD8 _ptr data;
struct munichRcDescr _ptr next;
}
MUNICH_RECEIVE_DESCRIPTOR;
PEB 20320
Appendix
User’s Manual 246 01.2000
typedef MUNICH_RECEIVE_DESCRIPTOR _ptr MUNICH_RC_DESCR_PTR;
/*--------------------------------------------------------------------------
- MUNICH32 Structures -
--------------------------------------------------------------------------
*/
typedef struct
{
unsigned channelNumber : 5;
unsigned rt : 1;
unsigned : 2;
unsigned fo : 1;
unsigned err : 1;
unsigned sf : 1;
unsigned ifc : 1;
unsigned fi : 1;
unsigned hi : 1;
unsigned arf : 1;
unsigned arack : 1;
unsigned x : 1;
unsigned sa : 1;
unsigned sb : 1;
unsigned e1 : 1;
unsigned e2 : 1;
unsigned e3 : 1;
unsigned e4 : 1;
unsigned e5 : 1;
unsigned e6 : 1;
unsigned e7 : 1;
unsigned frc : 1;
unsigned : 4;
unsigned intFlag : 1;
}
MUNICH32_INTERRUPT_QUEUE;
typedef struct
{
MUNICH32_INTERRUPT_QUEUE _ptr addr;
unsigned n : 8;
unsigned : 24;
}
INTERRUPT_QUEUE_SPECIFICATION;
typedef struct
{
unsigned rcFillMask : 8;
unsigned rcChannelNumber : 5;
PEB 20320
Appendix
User’s Manual 247 01.2000
unsigned rti : 1;
unsigned : 2;
unsigned txFillMask : 8;
unsigned txChannelNumber : 5;
unsigned tti : 1;
unsigned : 2;
}
TIME_SLOT_ASSIGNMENT;
typedef struct
{
unsigned iftf : 1;
unsigned mode : 2;
unsigned fa : 1;
unsigned trv : 2;
unsigned crc : 1;
unsigned inv : 1;
unsigned tflagCs : 1;
unsigned tflag : 7;
unsigned ra : 1;
unsigned ro : 1;
unsigned th : 1;
unsigned ta : 1;
unsigned to : 1;
unsigned ti : 1;
unsigned ri : 1;
unsigned nitbs : 1;
unsigned intMask : 8;
MUNICH_RC_DESCR_PTR frda;
MUNICH_TX_DESCR_PTR ftda;
unsigned itbs : 6;
unsigned : 26;
}
CHANNEL_SPECIFICATION;
typedef struct
{
WORD32 *currentReceiveDescriptorAddrCh;
}
CURRENT_RC_DESCR_ADDR;
typedef struct
{
WORD32 *currentTransmitDescriptorAddrCh;
}
CURRENT_TX_DESCR_ADDR;
PEB 20320
Appendix
User’s Manual 248 01.2000
typedef struct
{
unsigned : 2;
unsigned ia : 1;
unsigned loopi : 1;
unsigned loop : 1;
unsigned loc : 1;
unsigned res : 1;
unsigned im : 1;
unsigned channelNumber : 5;
unsigned : 1;
unsigned ico : 1;
unsigned in : 1;
unsigned mfl : 13;
unsigned pcm : 3;
}
ACTION_SPECIFICATION;
/*--------------------------------------------------------------------------
- MUNICH32 Control Block -
--------------------------------------------------------------------------
*/
typedef struct
{
ACTION_SPECIFICATION actionSpec;
INTERRUPT_QUEUE_SPECIFICATION intQueueSpec;
TIME_SLOT_ASSIGNMENT timeSlot 32;
CHANNEL_SPECIFICATION channelSpec 32;
MUNICH_RC_DESCR_PTR currRcDescrAddr 32;
MUNICH_TX_DESCR_PTR currTxDescrAddr 32;
}
MUNICH32_CTRL_CFG_SECTION;
..
..
PEB 20320
Appendix
User’s Manual 249 01.2000
/*--------------------------------------------------------------------------
- Function : InitChannel0AndSendFirstFrame -
--------------------------------------------------------------------------
- Description : Initialization of channel 0. -
- - PCM Highway format CEPT 32-channel -
- - HDLC Mode -
- - All timeslots are assigned to channel 0. -
- - Send th e fi rs t HDL C frame -
-------------------------------------------------------------------------*/
static void InitChannel0AndSendFirstFrame ( MUNICH_TX_DESCR_PTR m32TxDescr )
{
..
.. /*
-------------------------------------------------------------------------
*/
txDescr = m32TxDescr /* store transmit descriptor pointer */
/*=== Action Specification ==============================================*/
munichCtrlCfg.actionSpec.in = 1; /* initialization procedure */
munichCtrlCfg.actionSpec.ico = 0; /* initialize channel only */
munichCtrlCfg.actionSpec.channelNumber = 0; /* - */
munichCtrlCfg.actionSpec.im = 0; /* interrupt mask */
munichCtrlCfg.actionSpec.res = 0; /* reset */
munichCtrlCfg.actionSpec.loopi = 0; /* loops for test purposes */
munichCtrlCfg.actionSpec.loop = 0; /* loops for test purposes */
munichCtrlCfg.actionSpec.loc = 0; /* loops for test purposes */
munichCtrlCfg.actionSpec.ia = 1; /* interrupt attention */
munichCtrlCfg.actionSpec.pcm = 5; /* PCM, CEPT 32 channel */
munichCtrlCfg.actionSpec.mfl = 256;/* maximum frame length */
/*=== Interrupt Queue Specification =====================================*/
/* interrupt queue address */
munichCtrlCfg.intQueueSpec.addr = &munichIntQueue [0];
/* interrupt queue size */
munichCtrlCfg.intQueueSpec.n = (INT_QUEUE_SIZE_MAX / 16 -1);
for ( i = 0; i < INT_QUEUE_SIZE_MAX; i++ ) /* Reset interrupt queue */
{
munichIntQueue[i].intFlag = CLEAR;
}
PEB 20320
Appendix
User’s Manual 250 01.2000
/*=== Timeslot Assignment ===============================================*/
for ( i = 0; i < 32; i++)
{ /* For all timeslots */
munichCtrlCfg.timeSlot[i].rcChannelNumber = 0; /* assigned to */
munichCtrlCfg.timeSlot[i].txChannelNumber = 0; /* channel 0 */
munichCtrlCfg.timeSlot[i].rcFillMask = 0xFF;/* all bits assigned */
munichCtrlCfg.timeSlot[i].txFillMask = 0xFF;/* per channel */
munichCtrlCfg.timeSlot[i].tti = 0; /* Tx output active */
munichCtrlCfg.timeSlot[i].rti = 0; /* Rc input active */
}
/*=== Channel Specification =============================================*/
munichCtrlCfg.channelSpec[channel0].intMask = 0; /* interrupts enabled */
munichCtrlCfg.channelSpec[channel0].nitbs = 1; /* new ITBS value */
munichCtrlCfg.channelSpec[channel0].to = 0; /* transmit */
munichCtrlCfg.channelSpec[channel0].ta = 1; /* initialization */
munichCtrlCfg.channelSpec[channel0].ti = 1; /* */
munichCtrlCfg.channelSpec[channel0].ro = 0; /* receive */
munichCtrlCfg.channelSpec[channel0].ra = 1; /* initialization */
munichCtrlCfg.channelSpec[channel0].ri = 1; /* */
munichCtrlCfg.channelSpec[channel0].th = 0; /* no transmit hold */
munichCtrlCfg.channelSpec[channel0].fa = 0; /* no flag adjustment */
munichCtrlCfg.channelSpec[channel0].tflag = 0; /* only for TMA */
munichCtrlCfg.channelSpec[channel0].tflagCs = 0; /* CRC select */
munichCtrlCfg.channelSpec[channel0].inv = 0; /* no bit inversion */
munichCtrlCfg.channelSpec[channel0].crc = 0; /* 16-bit CRC */
munichCtrlCfg.channelSpec[channel0].trv = 0; /* transmission rate */
munichCtrlCfg.channelSpec[channel0].mode = 3; /* HDLC Mode */
munichCtrlCfg.channelSpec[channel0].iftf = 0; /* idle code flags */
munichCtrlCfg.channelSpec[channel0].itbs = 9; /* transmit buffer size */
munichCtrlCfg.channelSpec[channel0].ftda = txDescr; /* first transmit */
/* descriptor address */
PEB 20320
Appendix
User’s Manual 251 01.2000
/*=== Transmit Descriptor ===============================================*/
/* the next pointer of the last txDescr points to the zero pointer */
for ( ; txDescr ->next; txDescr = txDescr ->next )
{
txDescr ->fnum = 3; /* 3 interframe timefill char */
txDescr ->hold = 0; /* clear hold bit */
txDescr ->hi = 0; /* clear host initiated interrupt bit */
txDescr ->fe = 0; /* clear frame end bit */
txDescr ->v110 = 0; /* clear v110 bit */
}
txDescr ->fe = 1; /* set frame end bit */
txDescr ->hold = 1; /* set hold bit */
/*=== Receive Descriptor ================================================*/
rcDescr = AllocReceiveDescriptor(10); /* Alloc e.g. ten */
/* receive descriptors */
/* with 32 data byte each */
munichCtrlCfg.channelSpec[channel0].frda = rcDescr; /* first receive */
/* descriptor address */
/*=== Prepare Receive Descriptor 1 to 9 =================================*/
for ( ; rcDescr ->next; rcDescr = rcDescr ->next )
{
rcDescr ->hold = 0; /* not the last descriptor */
rcDescr ->hi = 0; /* no host interrupt */
rcDescr ->no = 32; /* 32 data byte available */
rcDescr ->fe = 0; /* clear frame end bit */
rcDescr ->c = 0; /* clear data section complete bit */
}
/*== = Prep are Th e Last Receiv e Descri ptor, Number 10 === ===== ======== ====* /
rcDescr ->hold = 1; /* last available descriptor */
rcDescr ->hi = 1; /* no host interrupt */
rcDescr ->no = 32; /* 32 data byte available */
rcDescr ->fe = 0; /* clear frame end bit */
rcDescr ->c = 0; /* clear data section complete bit */
channelControl[0].lasttxdescr = txDescr; /* store last transmit pointer */
channelControl[0].lastrcdescr = rcDescr; /* store last receive pointer */
MUNICH32_ACTION_REQUEST (); /* generate MUNICH32 activation request */
}
PEB 20320
Appendix
User’s Manual 252 01.2000
/*--------------------------------------------------------------------------
- Function : TxHdlcFrame -
--------------------------------------------------------------------------
- Description : Transmit an HDLC frame via channel 0 -
--------------------------------------------------------------------------
*/
static void TxHdlcFrame ( MUNICH_TX_DESCR_PTR m32TxDescr )
{
..
..
/*
-------------------------------------------------------------------------
*/
m32TxDescr = txDescr; /* store transmit descriptor pointer */
channelControl[0].lasttxdescr ->next = txDescr; /* Add frame to existing */
/* channel0 frame queue */
/*=== Transmit Descriptor ===============================================*/
for ( ; txDescr ->next; txDescr = txDescr ->next )
{
txDescr ->fnum = 3; /* 3 interframe timefill char */
txDescr ->hold = 0; /* clear hold bit */
txDescr ->hi = 0; /* clear host initiated interrupt bit */
txDescr ->fe = 0; /* clear frame end bit */
txDescr ->v110 = 0; /* clear v110 bit */
}
txDescr ->fe = 1; /* set frame end bit */
txDescr ->hold = 1; /* set hold bit */
channelControl[0].lasttxdescr ->hold = 0; /* the polling MUNICH32 */
/* will then detect the */
/* cleared hold bit and */
/* send the following */
/* frame */
channelControl[0].lasttxdescr = txDescr; /* store last transmit pointer */
}
