INFINEON PEB20320

ICs for Communications
Multichannel Network Interface Controller for HDLC
MUNICH32
PEB 20320 Version 3.4
User’s Manual 01.2000
DS3
•
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.
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
•
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.
Edition 01.2000
Published by Infineon Technologies AG,
SC,
Balanstraße 73,
81541 München
© Infineon Technologies AG 2000.
All Rights Reserved.
Attention please!
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 endangered.
PEB 20320
Preface
The Multichannel Network Interface Controller for HDLC (MUNICH32) is a Multichannel
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, Introduction
Gives a general description of the product and its family, lists the key features, and
presents some typical applications.
• Chapter 2, Functional Description
This chapter provides a detailed description of the interfaces and the protocol modes.
• 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, Appendix
This chapter provides source code examples.
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
[email protected]
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).
User’s Manual
3
01.2000
PEB 20320
User’s Manual
4
01.2000
PEB 20320
Table of Contents
Page
1
1.1
1.2
1.3
1.4
1.5
1.6
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Features
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Pin Definitions and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Logic Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
2
2.1
2.2
2.2.1
2.2.2
2.2.3
2.3
2.4
2.5
Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Serial Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Microprocessor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Intel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Motorola Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
DMA Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Basic Functional Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Detailed Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Boundary Scan Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
3
3.1
3.2
Operational Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Reset State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Initialization Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
4
4.1
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.3
4.4
Detailed Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Organization of the Shared Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Control and Configuration Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Action Specification (Read Once After Each Action Request Pulse) . . .136
Interrupt Queue Specification
. . . . . . . . . . . . . . . . . . . . . . .140
Interrupt Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Time Slot Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Channel Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
Current Receive and Transmit Descriptor Address
. . . . . . . . . . . . . .161
Transmit Descriptor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Receive Descriptor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
5
5.1
5.1.1
5.1.1.1
5.1.1.2
5.1.1.3
5.1.1.4
5.1.2
5.1.3
5.1.3.1
Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Test Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Test Loop Definitions for the MUNICH32 . . . . . . . . . . . . . . . . . . . . . . .173
Internal Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
External Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
Test Loop Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
Test Loop Deactivation and Switching . . . . . . . . . . . . . . . . . . . . . . . . . .176
Software Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
User’s Manual
5
01.2000
PEB 20320
Table of Contents
Page
5.1.3.2
5.1.4
5.1.4.1
5.1.4.2
5.2
5.2.1
5.2.2
5.2.3
5.2.3.1
5.2.3.2
5.2.4
5.2.5
5.2.6
5.2.7
5.3
5.3.1
5.3.2
Hardware Reset Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
Test Loop Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
MUNICH32 in a LAN/WAN Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Device Driver Module MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . .191
Application Module MROUTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
Adaption of the 68040 µP Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Memory Bus Occupancy for a Single MUNICH32 . . . . . . . . . . . . . . . . . . .214
Bus Occupancy Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
Bus Occupancy for Idle Tx Channels . . . . . . . . . . . . . . . . . . . . . . . . . .218
6
6.1
6.2
6.3
6.3.1
6.3.2
Application Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
Frequency Adaption in an Intel 368 Common Bus System . . . . . . . . . . . .220
MUNICH32 Memory Space Requirement . . . . . . . . . . . . . . . . . . . . . . . . .223
Serial Interface to different PCM Systems . . . . . . . . . . . . . . . . . . . . . . . . .224
MUNICH32 for SIEMENS Primary Access Interface . . . . . . . . . . . . . . .224
MUNICH32 in Systems with MITEL ST BUS . . . . . . . . . . . . . . . . . . . . .227
7
7.1
7.2
7.3
7.4
7.5
7.6
Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
Absolute Maximum Ratings
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
Capacitances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Microprocessor Interface Intel Bus Mode . . . . . . . . . . . . . . . . . . . . . . . . .232
Microprocessor Interface Motorola Bus Mode . . . . . . . . . . . . . . . . . . . . . .235
8
Package Outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
9
9.1
9.2
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Source Code Extract MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
User’s Manual
6
01.2000
PEB 20320
Introduction
1
Introduction
The Multichannel Network Interface Controller for HDLC (MUNICH32) is a Multichannel
Protocol Controller, which handles up to 32 data channels of a full duplex PCM highway.
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 these functions the MUNICH32 can be used in a wide area of telecommunication
and data communication applications, e.g. in central office switches, for the connection
of a digital PABX to a host computer, as a central D-channel controller to 32 ISDN basic
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.
User’s Manual
7
01.2000
Multichannel Network Interface Controller for HDLC
MUNICH32
Version 3.4
1.1
PEB 20320
CMOS
Features
• Serial Interface
– 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.
P-MQFP-160-1
– 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 checking (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 generation
Type
Package
PEB 20320
P-MQFP-160-1
User’s Manual
8
01.2000
PEB 20320
Introduction
– 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 abort case with programmable flag
– Transparent Mode B
– Transparent transmission/reception in frames delimited by 00H flags
– 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 data 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 generation 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
User’s Manual
9
01.2000
PEB 20320
Introduction
• 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-power CMOS technology
– TTL-compatible inputs/outputs
– 160 pin P-MQFP package
User’s Manual
10
01.2000
PEB 20320
Introduction
1.2
Pin Configuration
(top view)
A7
D7
V DD
V SS
A6
D6
A5
D5
V DD
V SS
V SS
A4
D4
A3
D3
V DD
V SS
V SS
A2
D2
BE0
D1
V DD
V SS
BE1
D0
BE2
VDD
V SS
BE3
W,R/R;W
V DD
V SS
V SS
DS/PCHK
ADS/AS
V DD
V SS
HOLD/BR
BGACK/PM
P-MQFP-160-1
120
121
110
100
90
81
80
130
70
MUNICH32
PEB 20320
140
60
150
50
Index
Marking
160
1
10
20
30
41
40
D20
A20
V SS
V DD
D21
A21
D22
A22
V SS
V SS
V DD
D23
A23
D24
A24
V SS
V DD
D25
A25
D26
A26
V SS
V SS
V DD
D27
A27
D28
A28/DP0
V SS
V SS
V DD
D29
A29/DP1
D30
A30/DP2
V SS
V DD
D31
A31/DP3
INT/INT
D8
A8
VSS
V DD
D9
A9
D10
A10
VDD
VSS
VDD
D11
A11
D12
A12
VSS
VDD
D13
A13
VDD
VSS
D14
A14
VSS
VDD
D15
A15
D16
A16
VSS
VSS
VDD
D17
A17
D18
A18
VSS
VDD
D19
A19
HLDAO/BGO
HLDA/BG
V DD
V SS
BERR
READY/DSACK
B16
I/M
N.C.
N.C.
N.C.
TCLK
TSP
TDATA
AR
TEST
V SS
V DD
V SS
SCLK
RESET
V SS
V DD
V DD
JTEST3
JTEST2
JTEST1
JTEST0
N.C.
CI4
CI3
CI2
CI1
CI0
RDATA
RSP
RCLK
N.C.
N.C.
N.C.
ITP03487
Figure 1
User’s Manual
11
01.2000
PEB 20320
Introduction
1.3
Pin Definitions and Functions
Pin Definitions and Functions
Pin No.
P-MQFP-160-1
Symbol
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
I
Ground (0 V)
All pins must have the same level.
73
I/M
I
Intel Bus Mode or Motorola Bus Mode
By connecting this pin to either VSS or VDD
the bus interface can be adapted to either
Intel or Motorola environment. The data is
interpreted either in Intel or Motorola
manner; i.e. little or big endian convention.
I/M = low: Intel bus mode
I/M = high: Motorola bus mode
39
A31
O
DP3
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).
A30
O
DP2
I/O
35
Input (I) Function
Output (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!
User’s Manual
12
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
33
A29
O
Address Bit 29
(Intel non-parity/Motorola) tristate when
unused.
DP1
I/O
Data Parity 1 (Intel parity mode),
bidirectional tristate line containing/
expecting parity bit of D(15:8)
A28
O
Address Bit 28
(Intel non-parity/Motorola) tristate when
unused
DP0
I/O
Data Parity 0 (Intel parity mode),
bidirectional tristate line containing/
expecting parity bit of D(7:0)
26, 21, 19, 15, A(27:2)
13, 8, 6, 2, 160,
156, 154, 149,
147, 143, 139,
135, 133, 128,
126, 122, 120,
116, 114, 109,
107, 102
O
Address Bus
tristate when unused.
91, 94, 96, 100
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.
28
User’s Manual
BE(3:0)
Input (I) Function
Output (O)
13
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
Input (I) Function
Output (O)
38, 34, 32, 27, D(31:0)
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
I/O
Data Bus
The data bus lines are bidirectional tristate
lines which interface with the system’s
data bus.
86
DS
O
Data Strobe (Motorola mode)
This signal indicates that valid data is to be
placed on the data bus (read cycle) or has
been placed on the data bus by the
MUNICH32 (write cycle).
PCHK
O
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
I
Supply voltage 5 V ± 5%
All pins must have the same level.
85
ADS
O
Address Status (Intel bus mode)
This signal indicates that a valid bus cycle
definition and address are being driven at
the pins.
AS
O
Address Strobe (Motorola bus mode)
A valid address is transmitted on the
address bus at the falling edge of AS.
In both cases this signal is active low and
tristate when unused.
User’s Manual
14
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
Input (I) Function
Output (O)
90
W/R
O
Write/Read (Intel bus mode)
This signal distinguishes write from read
operations.
R/W
O
Read/Write (Motorola bus mode)
This signal distinguishes between read
and write operations.
In both cases this signal is tristate when
unused.
75
User’s Manual
READY
I
Ready (Intel bus mode)
This signal indicates that the current bus
cycle is complete. When READY is
asserted during a read cycle the
MUNICH32 latches the input data and
terminates the cycle. When READY is
asserted during a write cycle the
MUNICH32 terminates the cycle.
DSACK
I
Data Transfer Acknowledge (Motorola
bus mode)
This active low input indicates that a data
transfer may be performed. During a read
cycle data becomes valid at the falling
edge of DSACK. The data is latched
internally and the bus cycle is terminated.
During a write cycle the falling edge of
DSACK marks the latching of data and the
bus cycle is terminated.
15
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
76
BERR
I
Bus Error (Intel and Motorola bus mode)
This active low signal informs the
MUNICH32 that a bus cycle error has
occurred. The MUNICH32 terminates 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 action is suspended. In case of an
erroneous 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 error condition no
further actions are performed by the
MUNICH32. Please see Chapter 2.2,
‘Microprocessor Interface’, first paragraph
and Figure 18.
As bus cycles are executed without time
limit this signal prevents a hang-up
situation of the MUNICH32.
74
B16
I
Word Operation
Setting this bit to VDD causes the
MUNICH32 to perform 32-bit long word
accesses to the shared memory, setting 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.
User’s Manual
Input (I) Function
Output (O)
16
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
82
HOLD
O
Bus Hold Request (Intel bus mode)
This signal is driven high when the
MUNICH32 requests the control of the
bus.
BR
I/O
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.
HLDA
I
Bus Hold Acknowledge (Intel bus mode)
This active high signal indicates that the
processor has released the control of the
bus. The MUNICH32 starts the bus cycles.
BG
I
Bus Grant (Motorola bus mode)
This active low signal indicates that the
MUNICH32 may assume the bus
mastership.
79
81
BGACK
PM
User’s Manual
Input (I) Function
Output (O)
I/O
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.
I
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.
17
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
80
HLDAO
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
deactivated in order to prevent blocking in
the case of continuous request by one
MUNICH32.
BGO
O
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.
AR
I
Action Request
AR must be pulsed low to cause an action
of the MUNICH32. The AR is activated 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.
66
User’s Manual
Input (I) Function
Output (O)
18
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
40
INT/INT
O
Interrupt Request
An interrupt is given when a transmission/
reception error is detected, frames are
received or transmitted, or a host initiated
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 frame.
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 32channel PCM format with 4.096-Mbit/s bit
rate.
61
SCLK
I
System Clock
PCM highway system clock highway
frequency
32-channel 16.384 MHz 2.048 or
4.096 MHz
24-channel 12.288 MHz 1.536 MHz
24-channel 12.352 MHz 1.544 MHz
User’s Manual
Input (I) Function
Output (O)
19
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
51 … 47
CI(4:0)
I
56 … 53
JTEST
(3:0)
I/O
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 this PCM output port
is push-pull for active bits in the PCM
frame and tristate for inactive bits.
68
TSP
I
Transmit Synchronization 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
User’s Manual
Input (I) Function
Output (O)
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’
Test Pins
The MUNICH32 supports the JTAG
boundary scan test and the JTAG test
standards.
20
01.2000
PEB 20320
Introduction
Pin Definitions and Functions (cont’d)
Pin No.
P-MQFP-160-1
Symbol
60
RESET
I
Reset
41, 42, 43, 52,
70, 71, 72
N.C.
-
No Connect
These pins are reserved and should not be
connected
User’s Manual
Input (I) Function
Output (O)
21
01.2000
PEB 20320
Introduction
1.4
Logic Symbol
VSS
BE (3:0)
RCLK
30
1)
RSP
32
RDATA
D (31:0)
TCLK
TSP
W/R R/W
TDATA
ADS/AS
Microprocessor
Bus
Interface
DS/PCHK
READY/DSACK
Serial
Interface
MUNICH32
PEB 20320
I/M
BERR
5
B16
CI (4:0)
HOLD/BR
4
HLDA/BG
TEST
JTEST (3:0)
BGACK/PM
System
Interface
RESET
HLDAO/BGO
SCLK
AR
VDD
INT/INT
ITL03488
1) A31/DP3, A30/DP2, A29/DP1, A28/DP0, A[27:2]
Figure 2
MUNICH32 Logic Symbol
User’s Manual
22
01.2000
PEB 20320
Introduction
1.5
Functional Block Diagram
TCLK
TSP
TDATA
TEST RESET SCLK
JTEST
CI (4:0)
4
5
RCLK
RSP RDATA
Serial Interface/Formatter Controller Unit
CD
TF
Transmit
Formatter
CSR
Configuration and
State RAM
RD
Receive
Deformatter
TB
Transmit Buffer
CM
DMA Controller
RB
Receive Buffer
MI
Microprocessor Bus Interface
32
BE (3:0) A (31:2) D (31:0)
ADS/ DS W/R READY/ HOLD/ HLDA/ BGACK HLDAO/
R/W DSACK BR
AS
BGO
BG PM
BERR INT/ AR B16 I/M
ITB03495
INT
Figure 3
Block Diagram of MUNICH32
User’s Manual
23
01.2000
PEB 20320
Introduction
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. Transmit 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 Deformatter 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 Transmit Formatter, Receive Deformatter are used in a multiplex 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.
User’s Manual
24
01.2000
PEB 20320
Introduction
1.6
System Integration
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
processor via a 32-bit µP interface. At the same time it performs protocol formatting and
deformatting as well as rate adaption for each channel independently. The host 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 one single time slot four different D-channels can be handled by four MUNICH32s.
Figure 4, Figure 5 and Figure 6 give a general overview of system integration of the
MUNICH32.
PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s)
HLDA
HLDA
HOLD
HLDA
HLDA
CPU
HLDA
3
MUNICH32
HOLD
HLDAO
HLDA
2
MUNICH32
HOLD
HLDAO
HLDA
1
MUNICH32
HOLD
HLDAO
HLDA
0
MUNICH32
HOLD
Up to 4
MUNICH32
HLDA
System Bus
Memory
Optional
CPU
ITS03489
Figure 4
General System Integration (Intel Bus Mode)
User’s Manual
25
01.2000
PEB 20320
Introduction
PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s)
HOLD
HLDAO
HLDA
MUNICH32
HLDA
HOLD
MUNICH32
System Bus
Memory
CPU
ITS03490
Figure 5
General System Interface (Intel Bus Mode)
PCM Highway
MUNICH32
CPU
BR
BG
BGACK
MUNICH32
BR
BG
BGACK
Up to 4
MUNICH32
System Bus
Memory
Optional
CPU
ITS03491
Figure 6
General System Interface (Motorola Bus Mode)
User’s Manual
26
01.2000
PEB 20320
Introduction
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 mode. An operation mode pin B16 enables the transfer of a 32 bit long
word in two consecutive 16 bit word operations.
Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11 illustrate how the MUNICH32
may be used in different applications, like in a Primary Rate Interface, a Router, a Packet
Switch and a Central D-Channel Handler, as part of an ISDN switching system.
T1/S2 Line
Line
Interface
FALC54
PEB 2254
Interrupt
Controller
System
Memory
PCM
System
Interface
System Bus
INT/INT
System Bus
Controller
AR
Host Interface
(Alternative B)
Local CPU Bus
MUNICH32
PEB 20320
CPU
Host Interface
(Alternative A)
CPU Bus Arbitration
ITS07372
Figure 7
Architecture of a Primary Access Board
User’s Manual
27
01.2000
PEB 20320
Introduction
PCM Highway
Signaling Highway
R
Interrupt
Controller
EPIC
PEB 2056
HSCX
SAB 82525
System
Memory
System Bus
INT/INT
AR
Host Interface
(Alternative B)
System Bus
Controller
Local CPU Bus
MUNICH32
PEB 20320
Host Interface
(Alternative A)
CPU
PCM
System
Interface
CPU Bus Arbitration
ITS04829
Figure 8
Architecture of a Central D-Channel Handler
User’s Manual
28
01.2000
PEB 20320
Introduction
V.24, V.21, V.35, ...
T1/S2 Line
Line
Interface
Line Driver
FALC54
PEB 2254
ESCC8
SAB 82538
Interrupt
Controller
System
Memory
System Bus
INT/INT
AR
System Bus
Controller
Local CPU Bus
PCM
System
Interface
MUNICH32
PEB 20320
CPU
CPU Bus Arbitration
ITS07374
Figure 9
Architecture of a Packet Switch/Router
User’s Manual
29
01.2000
PEB 20320
Introduction
T1/S2 Line
Line
Interface
FALC54
PEB 2254
Interrupt
Controller
PCM
System
Interface
System
Memory
System Bus
INT/INT
System Bus
Controller
AR
Local CPU Bus
Local CPU Bus
CPU
MUNICH32
PEB 20320
(not compatible
with Intel 386 or
Motorola 68020)
CPU Bus Arbitration
CPU Bus Arbitration
ITS07371
Figure 10
MUNICH32 in a System with a RISC CPU
Note: To reduce complexity the host interface is not explicitly shown here.
User’s Manual
30
01.2000
PEB 20320
Introduction
T1/S2 Line
Line
Interface
FALC54
PEB 2254
Interrupt
Controller
PCM
System
Interface
System
Memory
System Bus
INT/INT
System Bus
Controller
AR
Local CPU Bus
Local CPU Bus
Multi Port RAM
Controller
MUNICH32
PEB 20320
Multi Port
Memory
CPU Bus Arbitration
CPU
CPU Bus Arbitration
ITS07373
Figure 11
MUNICH32 in a System using Multiport Memory
Note: To reduce complexity the host interface is not explicitly shown here.
User’s Manual
31
01.2000
PEB 20320
Functional Description
2
Functional Description
2.1
Serial Interface
The serial interface of MUNICH32 includes a data receive (RDATA) and a data transmit
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
independent of each other, i.e. the frame positions and clock phases are not correlated.
Data is transmitted 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 PCM 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-numbered time slots, so all 64 time slots can be covered by connecting
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 purposes four different test loops can be switched. In a complete loop all logical
channels are mirrored either from serial data output to input (internal loop) or vice versa
(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.
User’s Manual
32
01.2000
PEB 20320
Functional Description
125 µs
SLOT 0
SLOT 1
F 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
SLOT 23
PCM - Frame
SLOT 23
SLOT 0
6
7
F
0
1
2
3
4
SLOT 1
5
6
7
TCLK
TSP
TDATA
FILL/MASK
Fill/Mask : Slot 0
T1/DS1 - Mode Transmit Frame Timing
SLOT 23
10011000
SLOT 0
6
7
F
0
1
DATA
DATA
2
3
4
SLOT 1
5
6
DATA
DATA
7
RCLK
RSP
RDATA
DATA
DATA
FILL/MASK
Fill/Mask : Slot 0
T1/DS1 - Mode Receive Frame Timing
11010110
ITD03496
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.
User’s Manual
33
01.2000
PEB 20320
Functional Description
125 µs
SLOT 0
SLOT 1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
SLOT 23
PCM - Frame
SLOT 23
SLOT 0
6
7
0
1
2
3
4
SLOT 1
5
6
7
TCLK
TSP
TDATA
FILL/MASK
Fill/Mask : Slot 0
T1/DS1 - Mode Transmit Frame Timing
SLOT 23
10011000
SLOT 0
6
7
0
1
DATA
DATA
2
3
4
SLOT 1
5
6
DATA
DATA
7
RCLK
RSP
RDATA
DATA
DATA
FILL/MASK
Fill/Mask : Slot 0
T1/DS1 - Mode Receive Frame Timing
11010110
ITD03497
Figure 13
T1/DS1 Mode PCM Frame Timing 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.
User’s Manual
34
01.2000
PEB 20320
Functional Description
125 µs
SLOT 0
SLOT 1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
SLOT 31
PCM - Frame
SLOT 31
SLOT 0
6
7
0
1
3
2
SLOT 1
5
4
6
7
TCLK
TSP
TDATA
FILL/MASK
Fill/Mask : Slot 0
CEPT - Mode Transmit Frame Timing
SLOT 31
10011000
SLOT 0
6
7
0
1
DATA
DATA
DATA
DATA
3
2
4
SLOT 1
5
6
DATA
DATA
7
RCLK
RSP
RDATA
DATA
FILL/MASK
Fill/Mask : Slot 0
CEPT - Mode PCM - Frame Timing
11010110
ITD03498
Figure 14
CEPT Mode PCM Frame 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.
User’s Manual
35
01.2000
PEB 20320
Functional Description
125 µs
SLOT 0
SLOT 1
SLOT 31
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
TSP
RSP
4.096 Mbit/s PCM-format: even numbered slot allocation
6 7
SLOT 0
SLOT 31
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
TSP
RSP
4.096 Mbit/s PCM-format: odd numbered slot allocation
ITD03528
Figure 15
4.096 Mbit/s PCM Frame 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.
User’s Manual
36
01.2000
PEB 20320
Functional Description
125 µs
0 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 x 64 kbit/s
1
0
2
1
3
4
1
5
6
7 8 7 9 1
ITD03499
Figure 16
Example: Programmable Channel Allocation for 32 Time Slots
125 µs
0
1
2
0
3
4
5
1
2
6
7
3
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 x 64 kbit/s
4
3
5
1
2
6
ITD03500
Figure 17
Example: Programmable Channel Allocation for 24 Time Slots
User’s Manual
37
01.2000
PEB 20320
Functional Description
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 GByte of RAM with a 30-bit address bus (A(31:2)). The chip always works 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 the write access belonging to the interrupt specification.
The timing of the microprocessor interface is established according to the Intel 80386 or
Motorola 68020 processor. The system clock (SCLK) provides the fundamental timing
for the µP interface and is the internal device 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 access the data of the two words are connected together to build a 32-bit long word
before processing.
Mode
Operation Mode B16
BE(3–0)
Access
Intel
1
0
0
0H
3H
CH
long word
MSB word
LSB word
Motorola
1
0
0
0H
8H
AH
long word
MSB word
LSB word
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).
User’s Manual
38
01.2000
PEB 20320
Functional Description
2.2.1
Intel Mode
The Intel mode has two submodes – parity mode (even parity) and non parity mode – to
be chosen by strapping PM to ‘1’ or ‘0’ respectively.
In Intel mode the lower (higher) ordered byte of a long word (D31 … D0) is assigned to
the lower (higher) ordered physical address.
The read or write bus cycle is controlled by the signals W/R, ADS and READY as shown
in Figure 18, Figure 19. Each bus cycle consists of two bus states (S1, S2). During state
S1 the address signals and bus cycle definition signals are driven valid. Simultaneously,
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 not asserted in S2 then wait
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 input data and parity bits DP3–0 (if parity mode is selected) is latched when READY
is asserted. During a write cycle MUNICH32 drives the data signals and parity bits DP3–
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 occurred, the MUNICH32 terminates the bus cycle. In case of a read cycle
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 error condition no actions are performed.
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) respectively. A low active output PCHK indicates
whether the parity was correct (PCHK = 1) or wrong (PCHK = 0) in the clock cycle after
the data/parity is latched. PCHK stays low 1 or 2 clock cycles. No further action is taken
as consequence to a parity fail.
As the memory access is performed by using one common system bus, bus
management is done with the signals HOLD, HLDA and HLDAO as shown in Figure 20.
The wired or HOLD line is driven high whenever one of the MUNICH32s has to perform
a bus transfer. The activated HOLD ACKNOWLEDGE indicates that the bus control will
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.
User’s Manual
39
01.2000
PEB 20320
Functional Description
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.
S1
READ
S2
S1
READ
S2
SW
SW
S1
BERR
S2
SCLK
A31-A2
BE(3:0)
[A27-A2]
W/R
Tristate
ADS
READY
BERR
[DP3-DP0], D(31:0)
[PCHK]
ITD03501
Figure 18
Read Cycle Timing Diagram (Intel mode)
User’s Manual
40
01.2000
PEB 20320
Functional Description
WRITE
WRITE
BERR
SCLK
A31-A2
BE(3:0)
[A27-A2]
Tristate
W/R
ADS
READY
BERR
[DP3-DP0], D(31:0)
INT
[PCHK]
ITD03502
Figure 19
Write Cycle Timing Diagram (Intel mode)
User’s Manual
41
01.2000
PEB 20320
Functional Description
MUNICH32
gets the Bus
Tristate
HOLD (intern)
Tristate
Tristate
Tristate
~~
HOLD (extern)
HLDA
No Bus
requests
~~
SCLK
Another Bus Master
gets the Bus
HLDAO
Bus Cycle
Max. 4 Clock Periods
ITD03503
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 most 4 clock periods after HLDA is asserted after its HOLD. The
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
consideration has a higher priority than the other bus master. HOLD (internal) is
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.
User’s Manual
42
01.2000
PEB 20320
Functional Description
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 control data transfer as shown 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
asserted half a clock cycle after the beginning of a bus cycle. The data strobe DS signal
is used as a condition for valid data of a write cycle. MUNICH32 asserts DS one full clock
cycle after the assertion of AS during a write cycle. The 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 cycle. The data is latched with the last
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 driven high half a clock period before bus cycle
end.
The bus error BERR is also a bus cycle termination indicator. It can be used in the
absence as well as in conjunction with DSACK. If an abnormal termination has occurred
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 indicate to the processor that one of the MUNICH32s requires control of the bus. The
activated Bus Grant (BG) signals the availability of the system bus. If the MUNICH32 has
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 finishing the last bus cycle, the Bus Grant Acknowledge is deactivated and the Bus
Grant is passed on. In order to prevent blocking in the case of continuous request by one
device, MUNICH32 does not generate another Bus Request before the external Bus
Request and Bus Grant Acknowledge have been deactivated.
After getting the bus mastership MUNICH32 drives the bus and starts the first bus cycle
one clock after assertion of BGACK. After finishing the memory access it releases the
bus and de-asserts BGACK at the same time.
User’s Manual
43
01.2000
PEB 20320
Functional Description
READ
READ
BERR
SCLK
A31-A2, BE (3:0)
Tristate
R/W
AS
DS
DSACK
D (31:0)
BERR
ITD03504
Figure 21
Read Bus Cycle Timing Diagram for Motorola Bus Mode
WRITE
WRITE
BERR
SCLK
A31-A2, BE (3:0)
R/W
Tristate
AS
DS
DSACK
D (31:0)
BERR
INT
ITD03505
Figure 22
Write Bus Cycle Timing Diagram for Motorola Bus Mode
User’s Manual
44
01.2000
PEB 20320
Functional Description
MUNICH32
gets the Bus
Another Bus Master
gets the Bus
No Bus
requests
SCLK
~~
Max. 4 Clock Periods
BR (extern)
BG
~~
BR (intern)
BGACK (extern)
BGACK (intern)
BGO
ITD03506
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 typical configuration example for a system with several bus masters is given
in Figure 6.
User’s Manual
45
01.2000
PEB 20320
Functional Description
2.2.3
DMA Priorities
Prioritization of Queueing DMA Cycles
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)
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 multimaster systems where several MUNICH32 devices share the system bus.
User’s Manual
46
01.2000
PEB 20320
Functional Description
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 block diagram is shown in Figure 3. MUNICH32 is designed to handle up to 32 data
channels of a 1.536/1.544 Mbit/s T1/DS1 24-channel, 2.048-Mbit/s CEPT 32-channel 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 transmission direction respectively (blocks TF = Transmit Formatter, 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 management, i.e. there exists 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
Configuration and State RAM (CSR) at the beginning of the time slot and reloaded to the
CSR at the end. The control unit (CD) controls the access to the CSR and allows writing
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
receives 32 bits for a channel it requests access to the parallel microprocessor bus. The
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 transmit buffer (TB) has a size of 64 long words (= 256 bytes). In this buffer, data 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 requirements a variable and programmable part of the buffer (ITBS)
must be allocated to each data channel (see Figure 26).
User’s Manual
47
01.2000
48
Bit 1
Bit 2
~~
~~
Bit 0
X1
X2
X3
~~
Active
Receive
Channel
(external)
SCLK
Active
Receive
Channel
(internal)
Bit 1
Bit 0
~~
~~
RCLK
Bit 7
~~
Figure 24
Multiplex Management Receive Direction
User’s Manual
RDATA
X0
X1
Load CD, CSR Data
for X 1 into RD
RD Protocol
Operation disabled
RDATA
CD
Protocol Operation
Phase of RD, CM
might write new
Channel Config
Data into CSR
CSR
X2
Wait Phase
no Operation of RD,
CM might write new
Channel Config
Data into CSR
RD
Reload RD
into CSR
Protocol
Operation disabled
Load CSR Data
for X 2 into RD
RD Protocol
Operation disabled
RDATA
CSR
CD
CSR
X1
X2
...
X1
CSR
RD
CM
FIFO
CM
RD
RD
01.2000
PEB 20320
ITD04397
Functional Description
CSR
49
Bit 0
~~ ~~
~~ ~~
Bit 7
Bit 1
Active Transmit
Channel (external)
X1
~~
X0
SCLK
Active Transmit
Channel (internal)
Bit 0
~~
~~
TCLK
Bit 7
Bit 6
~~
Figure 25
Multiplex Management Transmit Direction
User’s Manual
TDATA
X0
X1
Load CSR Data
for X 1 into TF
TF Protocol
Operation disabled
Protocol Operation
Phase of TF, CM
might write new
Channel Config
Data into CSR
CSR
Wait Phase
no Operation of TF
CM might write new
Channel Config
Data into CSR
TF
X2
Reload TF
into CSR, CD
TF Protocol
Operation disabled
TDATA
CSR
CD
X1
...
X1
TF
CM
FIFO
CM
TF
ITD04398
01.2000
PEB 20320
X1
X2
X0
Functional Description
CSR
CSR
PEB 20320
Functional Description
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
transmission rate of 64 Kbit/s.
The choice of the individual buffer size of each data channel can be made in the channel
specification (shared memory). The buffer size of one channel is changeable without
disturbing the transmission of the other channels.
CD
Active Transmit
Channel (internal)
Used as Address Offset for TB
TF
Unused
ITBS of Channel
X1
ITBS of Channel
X0
ITBS of Channel
X2
ITBS of Channel
X3
TB
64 Long Words
ITD04396
Figure 26
Partitioning of TB
User’s Manual
50
01.2000
PEB 20320
Functional Description
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.
CD
Stored in RB
together with Data/Status
Word from RD
Active Receive
Channel (internal)
RD
RB
64 Long Words
ITD04447
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 variable size
Descriptor and data sections for each channel.
User’s Manual
51
01.2000
PEB 20320
Functional Description
Receive
DATA
Receive
DATA
Interrupt
Queue
Receive
Descriptor
Receive
Descriptor
Receive
Descriptor
Transmit
DATA
Transmit
DATA
Transmit
Descriptor
Transmit
Descriptor
Transmit
Descriptor
Receive
DATA
Receive
DATA
ACTION SPEC.
INTERRUPT QUEUE Spec.
Time-Slot Assignment
Channel 0 spec.
CI(4:0)
Control Start
Address
Control and
Configuration
section
Channel 31 spec.
Current Receive Descriptor Address 0 ... 31
Current Transmit Descriptor Address 0 ... 31
ACTION SPEC.
INTERRUPT QUEUE Spec.
Interrupt
Queue
Receive
Descriptor
Receive
Descriptor
Receive
Descriptor
Transmit
DATA
Transmit
DATA
Transmit
Descriptor
Transmit
Descriptor
Transmit
Descriptor
Receive
DATA
Receive
DATA
Interrupt
Queue
Receive
Descriptor
Receive
Descriptor
Receive
Descriptor
Transmit
DATA
Transmit
DATA
Transmit
Descriptor
Transmit
Descriptor
Transmit
Descriptor
Receive
DATA
Receive
DATA
Interrupt
Queue
Receive
Descriptor
Receive
Descriptor
Receive
Descriptor
Transmit
DATA
Transmit
DATA
Transmit
Descriptor
Transmit
Descriptor
Transmit
Descriptor
Time-Slot Assignment
Channel 0 spec.
CI(4:0)
Control Start
Address
Control and
Configuration
section
Channel 31 spec.
Current Receive Descriptor Address 0 ... 31
Current Transmit Descriptor Address 0 ... 31
ACTION SPEC.
INTERRUPT QUEUE Spec.
Time-Slot Assignment
Channel 0 spec.
CI(4:0)
Control Start
Address
Control and
Configuration
section
Channel 31 spec.
Current Receive Descriptor Address 0 ... 31
Current Transmit Descriptor Address 0 ... 31
ACTION SPEC.
INTERRUPT QUEUE Spec.
Time-Slot Assignment
Channel 0 spec.
Channel 31 spec.
Current Receive Descriptor Address 0 ... 31
Current Transmit Descriptor Address 0 ... 31
CI(4:0)
Control Start
Address
Control and
Configuration
section
ITD03507
Figure 28
Memory Division for up to four MUNICH32
User’s Manual
52
01.2000
PEB 20320
Functional Description
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 size of a data section. It also includes control information like frame 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 the current transmit descriptor address into the CCS, and fills 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 interframe time-fill byte will be sent in order to perform rate adaption. 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’ and sending 2 more 10-octet
frames with ‘zeros’ which leads to a loss of synchronism on the peer side. An adjustment
for the inserted zeros in HDLC is programmable, which leads to a reduction of the
specified number of interframe time-fill by 1/8th of the number of zero insertions. This can
be used to send long HDLC frames with a more or less fixed data rate in spite of the zero
insertions. A maskable interrupt is generated before transmission is started again.
User’s Manual
53
01.2000
PEB 20320
Functional Description
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 pointer, (read in the poll where 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.
User’s Manual
54
01.2000
User’s Manual
55
Data
Sections
Transmit
Descriptors
...
Next
Transmit
Descr.
Data 1
Next
Transmit
Descr.
Data 2
Next
Transmit
Descr.
FE =1 FNUM2
H =1
FNUM1+1
Flag, Ι C, ... , Ι C Flag
FE = 1 FNUM1
H =0
Frame (Data 1, Data 2)
FE=0 FNUM0
H =0
Flag
Data 3
...
FNUM2
Flag, Ι C ,
. . . .
Frame ( Data 3 )
ΙC
Poll
H=1?
Ι C, Ι C , Ι C ,
Ι C , Flag
Poll
H=0
...
...
...
ITD04446
Data 4
Frame ( Data 4 )
PEB 20320
Functional Description
Figure 29
01.2000
PEB 20320
Functional Description
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 change occurs in the first frame which does not contain data of the
previous data section.
5. Neither FE nor H may be set to 1 during a normal operation of the mode. They
both lead to an abort of the serial interface.
User’s Manual
56
01.2000
User’s Manual
NO=2
57
Data
Sections
E, S, X,
Next
Transmit
Descr.
FE = 0 NO=8
H =0
V110 = 0
Data 1
Next
Transmit
Descr.
FE=0 NO = 5
H =0
V110 = 0
10 Octets
10 Octets
FE=0
H =0
Frame ( E, S, X, Data 1 (2) )
Frame ( E, S, X, Data 1 (1) )
Transmit
V110=1
Descriptors
Next
Transmit
Descr.
...00
Data 2
Next
Transmit
Descr.
FE = 0 NO=2
H =0
V110 = 1
10 Octets
Next
Transmit
Descr.
Data 3
10 Octets
ITD04444
. . . . .
Frame ( E, S, X, Data 2, (2) Data 3 (1) )
FE = 0 NO=9
H =0
V110 = 0
E´, S´, X´,
Frame ( E, S, X, Data 2 (1) )
10 Octets
Frame ( E´, S´, X´, Data 3(2) )
...
PEB 20320
Functional Description
Figure 30
01.2000
PEB 20320
Functional Description
Fixed Size Frame Oriented Protocols (V.110/X.30)
Handling of frame end (FE) indication
Note: 1. FNUM must be ‘0’ for all transmit descriptors.
2. The frame (E, S, X, DATA 2(2)) is the beginning of a 10-octet frame. It stops with
the octet no. y, containing the last data bit of DATA 2 to be sent.
3. Since y = 1, …, 10 the 20 + y times 00H characters sent afterwards cause the
peer station to recognize 3 consecutive 10-octet frames with frame error which
leads to a loss of synchronism in the peer station.
4. For y = 10 DATA 2 is identical to DATA 2(1) and 30 times 00H 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.
User’s Manual
58
01.2000
User’s Manual
FE=0
H =0
59
Data
Sections
Data 1
10 Octets
(1)
Data 2
FE=0
H =0
V110 = 0
10 Octets
(2)
(1)
Data 3
) Frame ( E, S, X, Data 1 , Data 2
FE = 1
H =0
V110 = 0
Frame ( E, S, X, Data 1
Transmit
V110 = 0
Descriptors
...
ITD04448
. . . .
y=1,...,10
10-y Octets
) Frame ( E, S, X, Data 2
(2)
)
20+y Octets
00,......,00
10 Octets
Frame ( E, S, X, Data 3
(1)
)...
PEB 20320
Functional Description
Figure 31
01.2000
User’s Manual
FE=0
H =0
10 Octets
60
Data
Sections
(1)
FE = 1
H =1
V110 = 0
Data 2
FE=0
H =0
V110 = 0
10 Octets
Data 3
ITD04449
. . . .
y=1,...,10
10-y Octets
(2)
(1)
(2)
) Frame ( E, S, X, Data 1 , Data 2 ) Frame ( E, S, X, Data 2 )
Data 1
Frame ( E, S, X, Data 1
Transmit
V110 = 0
Descriptors
...
20+y Octets
00,......,00
Poll
H=1?
00 00
Poll
H=0
10 Octets
... 00 00 Frame ( E, S, X, Data 3 (1) ) . . .
PEB 20320
Functional Description
Fixed Size Frame Oriented Protocols (V110/X.30)
Handling of hold (H) indication
Figure 32
01.2000
PEB 20320
Functional Description
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 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 pointer, (read in the poll where 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.
User’s Manual
61
01.2000
User’s Manual
62
Data
Sections
Transmit
Descriptors
Time-Slot
Boundaries
TC
Data 1
Next
Transmit
Descr.
FE=0 FNUM0
H =0
...
Data 1
Next
Transmit
Descr.
FE = 1 FNUM1
H =0
Data 2
...
Data 2
Next
Transmit
Descr.
FE=1 FNUM2
H =1
FNUM1+1
TC,..................,TC
...
Data 3
Data 3
...
. . . .
FNUM2
TC, TC,.............TC,
...
Poll
H=1?
Poll
H=0
...
TC, TC, TC,........TC, TC
...
Data 4
ITD04445
Data 4
...
PEB 20320
Functional Description
Figure 33
01.2000
PEB 20320
Functional Description
An activated transmission hold (hold bit in descriptor) prevents the MUNICH32 from
sending more data. If a frame end has not occurred just before, the current frame will be
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 Channel Specification (CCS) in addition to the hold bit in the descriptor.
Setting the transmit hold (TH) bit by issuing a channel command will prevent further
polling of the transmit 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 memory until the descriptor hold is withdrawn. Then TB is filled
again and the TF is activated only after enough data are provided in the TB to prevent a
data underrun.
The Reaction to the Transmit Hold Bit is now Discussed for the Different 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 typically 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 handed over to CD outside of a frame, TH = 1 prevents the MUNICH32
from sending the next frame.
User’s Manual
63
01.2000
Figure 34
User’s Manual
AR
∆t1
TH=1 in the Channel Specification
handed over from CM to CD
∆t2
TH=0 in the Channel Specification
handed over from CM to CD
. . . .
Flag Frame ( ..., Data 1 , Data 2 ) Flag, ΙC,
Ι C, Flag Frame ( Data 3 ) . . .
. . . .
64
...
FE = 1 FNUM2
H =0
FE=0
H =0
. . . .
Data 2
Data 3
01.2000
PEB 20320
ITD04450
Functional Description
Data 1
PEB 20320
Functional Description
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 statistical 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 00H characters no matter how fast the TH bit is withdrawn. 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 frame, all bits that were read into the MUNICH32 with the same 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.
User’s Manual
65
01.2000
PEB 20320
Functional Description
AR
∆ t1
... Frame ( E, S, X, Data 1 (1) )
TH=1 in the
Channel
Specificaton
handed over
from CM to CD
00 ... 00
10-y Octets
...
TH=0 in the
Channel
Specificaton
handed over
from CM to CD
∆t 2
...........
00 ... 00
20+y Octets
Frame ( E, S, X, Data 1 (3) ) . . .
10 Octets
FE= 0
H =0
. . . .
Data 1
ITD04454
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 statistical but typically only a few clock cycles.
3. The TH bit (as all channel commands) is not synchronized with the TB! (as
opposed to the H-bit in the descriptor) TH acts to the data stream currently sent.
User’s Manual
66
01.2000
Figure 36
User’s Manual
AR
∆t1
TH=1 in the Channel Specification
handed over from CM to CD
∆t2
TH=0 in the Channel Specification
handed over from CM to CD
Time-Slot Boundaries
Data 1 , Data 2 , TC,
. . . .
TC, TC, TC, Data 3 . . .
67
FE= 0 FNUM0
H =0
FE = 1
H =0
...
. . . .
Data 2
Data 3
01.2000
PEB 20320
ITD04452
Functional Description
Data 1
PEB 20320
Functional Description
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.
User’s Manual
68
01.2000
Figure 37
User’s Manual
AR
∆t1
TH=1 in the Channel Specification
handed over from CM to CD
∆t2
TH=0 in the Channel Specification
handed over from CM to CD
. . . .
Flag Frame ( ..., Data 1 ) Flag, ΙC, ... , Ι C,
Ι C,
... Ι C,
. . . .
ΙC, Ι C, Ι C , ... Ι C, Flag Frame ( Data 2 ) . . .
...
FNUM0
Poll
H=1?
...
No Poll
Poll
H=1?
Poll
H=0
69
...
FE= 1 FNUM0
H =1
. . . .
Data 2
01.2000
PEB 20320
ITD04451
Functional Description
Data 1
PEB 20320
Functional Description
Fixed Size Frame Oriented Protocol (V110/.30)
Silencing of poll cycles by TH = 1
Note: 1. The times ∆t1 and ∆t2 are statistical but typically only a few clock cycles.
2. The TH bit (as all channel commands) is not synchronized with TB! (as
opposed to the H-bit in the descriptor) TH acts 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 pulse for an action specification leading to TH = 1 should be issued after
(ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed
number of long words in the TB reserved for this channel.
User’s Manual
70
01.2000
Figure 38
User’s Manual
AR
∆t 1
Frame ( E, S, X, Data 1 (1) ) Frame ( E, S, X, Data 1 (2) )
00 ... 00
TH=1
in the
Channel
Specif.
handed
over to CD
∆t 2
...........
TH=0
in the
Channel
Specif.
handed over
from CM to CD
00 ... 00
10-y Octets
10 Octets
Frame ( E, S, X, Data 2 (1) ) . . .
10 Octets
Poll
H=1 H=1
No Poll
Poll
H=1 H=0
71
20+y Octets
...
FE= 1
H =1
. . . .
Data 2
01.2000
PEB 20320
ITD04455
Functional Description
Data 1
PEB 20320
Functional Description
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 second frame solely depends on the AR low pulse leading to the action
with the channel with TH = 0.
3. The times ∆t1 and ∆t2 are statistical but typically only a few clock cycles.
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 data stream is stopped and TC sent after the last byte of DATA 2 is sent.
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 pulse for an action specification leading to TH = 1 should be issued after
(ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed
number of long words in the TB reserved for this channel.
User’s Manual
72
01.2000
Figure 39
User’s Manual
AR
∆ t1
TH=1 in the Channel Specification
handed over from CM to CD
∆ t2
TH=0 in the Channel Specification
handed over from CM to CD
. . . .
... Data 1 , TC, TC, ... , TC, TC,
. . . .
... TC,
TC, TC, TC , ... TC,
...
FNUM0
Poll
H=1?
Data 2 . . .
...
No Poll
Poll
H=1?
Poll
H=0
73
...
FE= 1 FNUM0
H =1
. . . .
Data 2
01.2000
PEB 20320
ITD04453
Functional Description
Data 1
PEB 20320
Functional Description
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
between the on-chip receive buffer and the external memory. After the data section has
been filled, the MUNICH32 writes the number of stored bytes (BNO) into the descriptor.
If a frame end has occurred the frame status is written into the descriptor and an interrupt
is generated. The frame status includes the CRC check 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 interface. The interframe time-fill code is sent after 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 initialization and control the host sets up a Control and Configuration Section (CCS),
including the action specification, interrupt queue specification, time slot assignment and
the channel specification. The host initiates an action, e.g. reconfiguration, change 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 start address, then the action specification and, if necessary, additional
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.
User’s Manual
74
01.2000
PEB 20320
Functional Description
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 frame 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.
User’s Manual
75
01.2000
PEB 20320
Functional Description
2.4
Detailed Protocol Description
In the following sections the protocol support of the MUNICH32 is described 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 interframe time-fill character in the channel specification
– 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, 7EH, 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
transmit descriptor as shown in Figure 40. This allows for a more or
less constant bit rate transmission for long HDLC frames.
User’s Manual
76
01.2000
PEB 20320
Functional Description
7 EH
Frame 1
7 EH . . . . . . 7 EH Frame 2
x Zero
Insertions
y= max (FNUM - [
FE=1
y+1
x
], 0)
8
FNUM
Data
Contents
of
Frame 1
Data
Contents
of
Frame 2
ITD04579
Figure 40
x
x
--- is the biggest integer smaller than --- .
8
8
x
1. For FNUM – --- < 0, y = 0
8
Note: 1.
– the kind of Frame Check Sequence (FCS)
two kinds of frame check sequences are implemented by the CRC bit in the
channel specification
CRC = 0: the generator polynomial x16 + 12 + x5 + 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 suppression of the automatic generation of the FCS is programmable in
the channel specification:
– CS = 0: FCS generated automatically
CS = 1: FCS generation suppressed
and in the transmit descriptor
CSM = 0: FCS generated automatically if CS = 0 in the
channel specification
CSM = 1: FCS generation suppressed
User’s Manual
77
01.2000
PEB 20320
Functional Description
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 MUNICH32 was unable to access the shared memory in time either 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
… ITF
FLAG
DATA
FCS
FLAG
ITF
…
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 adjustment)
MODE = 11 (HDLC)
IFTF = 1
(interframe time-fill ‘1’s)
INTEL interface
Channel number 1A
User’s Manual
78
01.2000
PEB 20320
Functional Description
Generate FI, HI-Int.
2000181A
Generate FI-Int.
2000081A
Generate FI-Int.
2000081A
1st Desc
31
0
2 nd Desc
31
0
3 rd Desc
31
0
A0010002
80060801
80030800
0
0
31
0
31
0
FF FF FF FF
0
AA
00 FF
FE=1
HOLD=0
HI=1
NO=1
CSM=0
FNUM=2
FLAG
0
FA 28 AA
Address
FE=1 Increases
HOLD=0
HI=0
NO=3
CSM=1
FNUM=0
FE=1
HOLD=0
HI=0
NO=6
CSM=1
FNUM=1
Time Increases
31
Zero Insertion
DATA 1
1
FCS
2
FLAG
ITF
3
..... 01111110 01010101 00010100010111110 01111110 11111111
8 Zero Insertion
4
DATA 2
FLAG
FLAG
5
01111110 111110111110111110111110111110111110111110111110 00000000 01111110
Zero Insertion
DATA 3
FLAG
0101010100010100010111110 01111110
ITD04578
Figure 41
Note: 1. Data is transmitted according to §2.8 of CCITT 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.
1
4. There was 1 zero insertion in the 1st frame, so FNUM – --- = FNUM = 2.
8
Therefore between the first and the second frame we have
FLAG ITF FLAG and ITF = FFH because IFTF = 1.
User’s Manual
79
01.2000
PEB 20320
Functional Description
5. No FCS is generated here as CSM is ‘1’ for the second and third transmit
descriptor. The FCS is supposed to be the last 2 bytes to be transmitted in this
case, their validity is not checked internally.
6. There was 8 zero insertions in the 2nd frame, so FNUM –
Therefore between the second and the third frame we
have a shared FLAG.
8
--8
= FNUM – 1 = 0.
For CS = 1 (CRC select) the transmitted data stream would differ at FCS, FCS would just
be omitted.
For INV = 1 (channel inversion) all bits of the data stream (including FLAG, DATA, FCS,
ITF) would be inverted.
For CRC = 1 (CRC 32) the transmitted data stream would only differ 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
DATA 2
FLAG
0111 111
FLAG
DATA 3
0111 111
Figure 42
For IFTF = 0 (ITF flags) the transmitted data stream would only differ at ITF, the 8 ones
would be replaced by 0111 1110.
For Motorola interface the only difference is in the data section
For the first descriptor it ought to be
31
0
AA
and for the second
31
0
FF FF FF FF
FF 00
and for the third
31
AA 28
0
FA
User’s Manual
80
01.2000
PEB 20320
Functional Description
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
divisible 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 is checked
to be greater than (case NSF = 0 only)
(case NSF = 0 only)
check a)
(only for CS = 0)
check b)
16 for CRC = 0
32 for CRC = 1
32 for CRC = 0
48 for CRC = 1
(case NSF = 1 & CS = 1 only) check a’) 8 for CRC = x (ignored)
8. The occurrence of an abort flag (7FH) ending a frame is checked.
More detailed description of the individual features:
1. a. A frame is supposed to have started if after a sequence of 0111 1110 in the receive
data stream neither FCH nor FDH nor 7EH has occurred. The frame is supposed to
have started with the first bit after the closing ‘0’ of the sequence.
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 frame is also supposed to have stopped if more than MFL bytes were received
since the start of the frame and it wasn’t stopped yet.
c. The ending flag of a frame may be the starting flag of the next frame (shared flags
supported).
User’s Manual
81
01.2000
PEB 20320
Functional Description
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.
RESET or Receive OFF
Receive Initialize
Channel Command
O
011111101111110 or
0111111001111110
in the Data Stream
(2 contiguous Flags
received, Flags with
shared Zeros
supported)
F
111111111111111
in the Data Stream
(15 contiguous "1"s
received) or a
Receive Abort Channel
Command during 15
received Bits
ITD04577
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
insertions are supposed to be the FCS of the remaining 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.
User’s Manual
82
01.2000
PEB 20320
Functional Description
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 abort channel command or from a receive descriptor with set HOLD bit.
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 + x12 + x5 + 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 received data is programmable 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 for frames which do not lead to data transfer as discussed in 7. of the
protocol features)
(maskable by FIR in the channel spec.)
IFC: issued if a change of the interframe time-fill state as discussed in 2. has occurred.
(maskable by IFC in the channel spec.)
SF:
a frame not fulfilling check a) has been detected (maskable by SFE in the
channel spec.)
User’s Manual
83
01.2000
PEB 20320
Functional Description
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 channel 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 channel 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
MFL = 10
User’s Manual
84
01.2000
PEB 20320
Functional Description
FLAG
.....
1
DATA 1, FCS 1
01111110 0100 0011 1000 0101 1000 0000 1100 0000 1001 1100 0000 0001
10111100
2
DATA Ignored up to next Flag
0011 1101 0011 11100 0011 1000 0110 0011 1101 1011 0010 0100
Abort Sequence
3
01111111
Generate HI-Int.
8800203D
1st Desc
31
0
2 nd Desc
31
4
0
000C0000
C0031C00
20080000
40080000
DATA 2
Generate FI, ERR-Int.
8800123D
31
0
C2 A1 01 03
39 80 3D BC
31
0
CRCO,
NOB,
LFD 5
Last Access of
a LFD Frame
should be Ignored
ITD04576
Figure 44
User’s Manual
85
01.2000
PEB 20320
Functional Description
Zero Insertion
FLAG
01111110
(shared) FLAG
01111110
DATA 2
0000 0000 0011 0101 1001 0010 1101 1111 0
Zero Insertion
FCS 2
0000 0011 0010 0101 0100 1111 0101 1111 0
Zero Insertion
6
DATA 3
0000 0000 0011 0101 1001 0010 1101 1111 0
Zero Insertion Missing
FCS 3
0000 0011 0010 0101 0100 1111 0101 1111
FLAG
01111110
Generate FI, HI-Int.
8800303D
3 rd Desc
31
0
4 th Desc
31
0
200C0000
C0080000
000C0000
C0081800
DATA 2
31
0
00 AC 49 FB
FCS 2
C0 A4 F2 FA
CRCO,
NOB
Generate FI, ERR-Int.
8800123D
31
0
00 AC 49 FB DATA 3
ITD04575
Last Access of
a NOB Frame
should be Ignored
Figure 45
User’s Manual
86
01.2000
PEB 20320
Functional Description
FCS 4
DATA 4
0101 0101 1101 1110 1010 0101 1000 0000 0010 0111
2 Flags with shared 0
FCS 5
0111 1110 111 1110
FLAG
01111110
0000 0000 0000 0000 0000 0000 0000 0000
FCS 6
DATA 6
Abort Sequence
0101 0101 1101 1110 1010 0101 1000 0000 0010 0111
DATA Ignored up to next Flag
FLAG
01111110
01111111
15 x "1"
7
1 1111110101000110011100111010 0111 1111 1111 1111 01110 011111100011111101111111
Generate FI-Int.
8800103D
Generate IFC-Int.
(2 Flags)
8800083D
Generate short
Frame
Interrupt for FCS 5
8800143D
9
10
5
5 th Desc
31
0
6 th Desc
31
0
000C0000
C0050000
00140000
C0050200
DATA 4
FCS 4
8
31
0
AA 7B A5 01
E4 XX XX XX
12
RA
Generate FI, ERR-Int.
8800123D
Generate IFC-Int. 11
(15 * 1)
8800083D
Generate Short Frame Interrupts
8800163D
8800163D
31
0
AA 7B A5 01
E4 XX XX XX
ITD04574
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 formatted as ordinary data!!!
User’s Manual
87
01.2000
PEB 20320
Functional Description
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 bytes in the last write access to the receive data section of the 5th
descriptor have to be ignored.
10.The 2 flags with a shared 0 in the middle change the original interframe timefill state ‘0’ of the receiver to ‘F’. The 2 flags following FCS 5 on the other 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
Generate
HI, FI, ERR-Int.
8800323D
1st Desc 1
31
0
3 rd Desc 2
31
0
20080000
C0071C00
200C0000
C0040000
31
0
C2 A1 01 03
Generate HI, FI-Int.
8800303D
31
0
00 AC 49 FB
ITD04572
Last Access of a LFD Frame
should be Ignored
Figure 47
User’s Manual
88
01.2000
PEB 20320
Functional Description
Generate FI, ERR-Int.
8800123D
Interrupts as in
the original Example
4 th Desc
31
0
5 th Desc
31
0
6 th Desc
31
0
000C0000
C0041800
000C0000
C0014000
00140000
C0014200
31
CRCO, NOB
0
SF
31
0
AA XX XX XX
SF, RA
31
0
AA XX XX XX
ITD04573
Last Access of a NOB Frame
should be Ignored
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 sequence 15 × ‘1’) are interpreted inversely. e.g. ‘1000 0001’ would be interpreted
as flag 15 × ‘0’ would lead to a change from interframe time-fill state ‘F’ to ‘0’ etc.
User’s Manual
89
01.2000
PEB 20320
Functional Description
For CRC = 0 (CRC 16) the correct FCS e.g. zeros for DATA 4 would be
00001 0100 0101 1110 the 5th descriptor would then be
5 th Desc
31
0
000C0000
C0034000
31
0
AA 28 FA XX
ITD04570
Figure 49
For Intel interface the only difference is in the receive data sections. They would be
of 1st Desc
31
0
03 01 A1 C2
BC 30 80 39
of 3 rd Desc
31
0
FB 49 AC 00
FA F2 A4 C0
of 5 th Desc
31
0
01 A5 7B AA
XX XX XX E4
ITD04571
Figure 50
User’s Manual
90
01.2000
PEB 20320
Functional Description
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
FNUM = 1
FNUM = 2
… frame 1, 00H, frame 2 … (start = end flag)
… frame 1, 00H, 00H, frame 2 …
… frame 1, 00H, 00H, 00H, frame 2 …
Interrupts
The possible interrupts for the mode in transmit direction are identical to those of HDLC.
A typical data stream has the form
ITF DATA ITF DATA
Example
TMB channel with
INV = 0
(no inversion)
CRC = 0
(required)
TRV = 00
(required)
FA = 0
(required)
MODE = 01 (TMB)
IFTF = 0
(required)
Intel interface
Channel number 5
User’s Manual
91
01.2000
PEB 20320
Functional Description
Generate FI-Interrupt
88001005
Generate HI-Interrupt
88002005
2
31
31
0
20020000
Generate FI-Interrupt
88001005
3
0
31
80000000
0
80030001
0
0
31
31
0
CE AB
0
45 23 01
1
FLAG
..... 0 0
DATA 1 FLAG
DATA 2
2 FLAGS
D 5 7 3 0 0 8 0 C 4 A 2 0 0 0 0 .....
ITD04569
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.
User’s Manual
92
01.2000
PEB 20320
Functional Description
TMB
Receive Direction
General Features
1. The starting and ending flag (00H before and after a frame) as well as interframe timefill 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
sequence 00H is the 8 m + 1st bit since the starting ‘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 one are transferred to the shared memory. The bytes
of the last access to the receive data section of the frame may contain erroneous bits
and shouldn’t be evaluated. LFD is always accompanied by NOB.
Options
There are no options in receive direction for this mode.
User’s Manual
93
01.2000
PEB 20320
Functional Description
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
User’s Manual
94
01.2000
PEB 20320
Functional Description
FLAG
DATA 1
1
00000000
10111001
10000000
octet
synchronous
FLAG
3
00000000
00
octet
synchronous
FLAG
DATA 2
11001011
00000000
DATA 3
10000000
(start) FLAG
non octet
synchronous
FLAG
10111100
0000000
4
DATA 4
10000000
11111110
01111111
11111011
11010101
01001100
DATA Ignored
up to next Framestart
5
FLAG
10100000
11110111
01010101
Generate FI,
8800302A
Generate FI-Int.
8800102A
DATA 5
0000 0000 0000 10101101
HI-Int.
1 st Desc
31
0
2 nd Desc
31
0
3 rd Desc
31
0
00040000
C0020000
200C0000
C0010000
20080000
C0020800
DATA 1
2
31
0
9D 01 XX XX
31
0
DATA 2 D3 XX XX XX
FLAG
00101010
0000 0000
Generate FI,
8800322A
HI, ERR-Int.
31
NOB
0
ITD04568
DATA 3
Last Access of a NOB Frame
should be Ignored
Figure 52
User’s Manual
95
01.2000
PEB 20320
Functional Description
Generate FI,
8800122A
Generate HI-Int.
8800202A
4 th Desc
31
0
5 th Desc 6
31
0
6 th Desc
31
0
20080000
40080000
00040000
C0000C00
00FC0000
C0020000
DATA 4
31
0
01 7F FE DF
LFD, NOB
Generate FI-Int.
8800102A
ERR-Int.
DATA 5
31
0
B5 54 XX XX
ITD04567
Last Access of a LFD Frame
should be Ignored
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 octet synchronous (end) flag of one frame can be part of the (start) flag 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.
Therefore the frame belonging to DATA 3 is supposed to have ended non-octet
synchronously (NOB set in the 3rd descriptor).
5. After MFL + 1 data bytes the further data are ignored and 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.
User’s Manual
96
01.2000
PEB 20320
Functional Description
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
of 1st Desc
31
0
XX XX 01 9D
of 2 nd Desc
31
0
XX XX XX D3
of 4 th Desc
31
0
DF FE 7F 01
of 6 th Desc
31
0
XX XX 54 B5
ITD05034
Figure 54
User’s Manual
97
01.2000
PEB 20320
Functional Description
TMR
Transmit Direction
General 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
FNUM = 1
FNUM = 2
… frame 1, 000H, frame 2 …
… frame 1, 00H, 00H, frame 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
User’s Manual
98
01.2000
PEB 20320
Functional Description
Generate FI-Interrupt
88001005
Generate HI-Interrupt
88002005
2
31
31
0
20020000
Generate FI-Interrupt
88001005
3
0
31
80000000
0
80030001
0
0
31
31
0
0E AB
0
45 23 01
1
FLAG
..... 0 0
DATA 1
FLAG
DATA 2
2 FLAGS
ITD04566
D 5 7 0 0 0 8 0 C 4 A 2 0 0 0 0 .....
Frame of Effective
Length 1 1/2 Byte
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.
User’s Manual
99
01.2000
PEB 20320
Functional Description
TMR
Receive Direction
General 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 started
– 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 both cases the eighth bit of the sequence 00 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.
If NOB = 1 the last byte of the last access to a receive data section of the frame may
contain erroneous bits and shouldn’t be evaluated. This does not affect the reception
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 transferred to the shared memory. The bytes of the last access to
the receive data section of the frame may contain erroneous bits and shouldn’t be
evaluated.
LFD is always accompanied by NOB.
User’s Manual
100
01.2000
PEB 20320
Functional Description
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
(required)
MFL = 7
Motorola interface
Channel No. 15
User’s Manual
101
01.2000
PEB 20320
Functional Description
(start) FLAG
.... 00000000
DATA 1
1
00000000
10111001
10000000
octet synchronous
(end) FLAG 2
00000000
octet synchronous
FLAG
DATA 2
00000000
11001011
0000
00000000
00000000
(start) FLAG
non octet
synchronous FLAG
DATA 3
10000000
00000000
10111100
11110101
11000000
3
0000 11110001 11011111 01011001 01101010
00000000
DATA Ignored
up to next Framestart
octet synchronous
(end) FLAG
4
DATA 4
11110011 11110111
11011101 11011011
11111111
00000000
DATA 5
00000000
Generate FI, HI-Int.
88003035
Generate FI-Int.
88001035
2 nd Desc
31
0
3 rd Desc
31
0
00040000
C0030000
200C0000
C0020000
00080000
C0060800
5
31
0
DATA 2 D3 00 XX XX
31
0
9D 01 00 XX
01111010
00000000
00000000
Generate FI, ERR-Int.
88001235
1 st Desc
31
0
DATA 1
11011101
NOB
31
0
01 00 3D AF
03 XX XX XX
Last Byte of
a NOB Frame
should be Ignored
DATA 3
Generate
FI, HI, ERR-Int.
88003235
Generate HI-Int.
88002035
Generate FI-Int.
88001035
4 th Desc
31
0
5 th Desc 6
31
0
6 th Desc
31
0
20080000
40080000
20040000
C0000C00
00080000
C0030000
31
0
DATA 4 8F FB 9A 56
31
0
DATA 5 BB 5E 00 XX
LFD, NOB
Last Access of a LFD Frame
should be Ignored
ITD04565
Figure 56
User’s Manual
102
01.2000
PEB 20320
Functional Description
1. After receive initialization is detected all data are ignored until a starting sequence
(16 ‘zeros’, ‘one’) is detected.
2. The octet synchronous (end) flag of one frame can be 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 data bytes the further data are ignored and are neither stored in the RB
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 descriptor (5th descriptor) even if no further data are to be given to the shared
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
of 1st Desc
31
0
XX 00 01 9D
of 2nd Desc
31
0
XX XX 00 D3
of 3rd Desc
31
0
AF 3D 00 01
XX XX XX 03
of 4th Desc
31
0
56 9A FB 8F
of 6 th Desc
31
0
XX 00 5E BB
ITD05035
Figure 57
User’s Manual
103
01.2000
PEB 20320
Functional Description
TMA
Transmit Direction
General 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
specification. The fill-character (TC) is then programmed in the TFLAG. For 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
FNUM = 1
FNUM = 2
… DATA 1, TC, DATA 2 …
… DATA 1, TC, TC, DATA 2 …
… DATA 1, TC, TC, TC, DATA 2 …
Interrupts
The possible interrupts for this mode in transmit direction are identical to those of HDLC.
User’s Manual
104
01.2000
PEB 20320
Functional Description
Example 1:
(no subchanneling by fill/mask bits)
TMA channel with
TFLAG = B2H
INV = 0
(no data inversion)
CRC = 0
(required)
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
Time-Slot
Boundaries
Bit No
0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0
DATA 1
.....
1
DATA 2
TC
2
DATA 3 2 TCs
DATA 4
D 5 8 B 6 C 4 8 0 0 B 2 4 F B 2 B 2 8 B B 4 4 C .....
Generate HI-, FI-Interrupt
8800300D
Generate HI-Interrupt
8800200D
1 st Desc
31
0
2 nd Desc
31
0
3 rd Desc
31
0
4 th Desc
31
0
20020000
A0030000
80010001
00030000
0
0
0
31
0
DATA 1 XX XX D1 AB
31
0
DATA 2 XX 00 12 36
For INV=1 DATA and TC would be Inverted
31
0
DATA 3 XX XX XX F2
0
31
0
DATA 4 XX 32 2D D1
ITD04564
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.
User’s Manual
105
01.2000
PEB 20320
Functional Description
For INV = 1 the data stream would be inverted completely
DATA 1 DATA 2
… 2A 74
TC DATA 3 2 TCs
93 B7 FF 4D
B0
DATA 4
4D 4D 74 4B B3 …
Figure 59
For FA = 0 TFLAG has to be programmed to 00H and the data stream would be
DATA 1 DATA 2
TC DATA 3 2 TCs
D5 8B 6C 48 00 FF
4F
DATA 4
FF FF 8B B4 4C
Figure 60
For Motorola mode the data sections leading to the same data stream would have been
of 1st Desc
31
0
AB D1 XX XX
of 2nd Desc
31
0
36 12 00 XX
of 3 rd Desc
31
0
F2 XX XX XX
of 4 th Desc
31
0
D1 2D 32 XX
ITD05036
Figure 61
User’s Manual
106
01.2000
PEB 20320
Functional Description
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
(required)
Intel interface
Channel no. D
Generate HI-Interrupt
8800200D
Generate HI-Interrupt
8800200D
1 st Desc
31
0
2 nd Desc
31
0
3 rd Desc
31
0
4 th Desc
31
0
20020000
A0030000
80010001
00030000
0
0
0
31
0
DATA 1 XX XX D1 AB
31
0
DATA 2 XX 00 12 36
31
0
DATA 3 XX XX XX F2
0
31
0
DATA 4 XX 32 2D D1
ITD04563
Figure 62
User’s Manual
107
01.2000
User’s Manual
0 12345670 12345670 12345670 12345670 12345670 1234567
108
Slot Boundaries
0 12345670 12345670 12345670 12345670 12345670 1234567
ITD04561
TC (FF)
2 TCs (FF FF)
DATA 4 (8B B4 4C)
ITD04562
0 10Z 11111Z 11111Z 111Z 1111Z000 1Z 11ZZ 110Z00Z 100 1100
External Data
DATA 3 (4F)
0 100 111111111111111111111000 10 1110 110 1000 100 1100
Internal Data
1110 111110 111110 1110 11110 11110 1100 1110 110 1111111
Fill/Mask
High Imp. Overwrite
Bit No
DATA 2 (6C 48 00)
Z 1ZZ0 1Z 11000 10 11ZZZZZZZZ0 1Z0 10Z0000Z0Z00ZZ 111111
External Data
(TDATA)
DATA 1 (D5 8B)
110 10 10 11000 10 110 110 11000 100 100000000000 11111111
Internal Data
0 100 110 11111111100000000 110 1110 11110 10 1100 111111
Fill/Mask
High Imp. Overwrite
Bit No
Slot Boundaries
PEB 20320
Functional Description
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.
01.2000
PEB 20320
Functional Description
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 programmable flag extraction
is performed automatically.
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
(required)
TRV = 00
(required)
FA = 1
MODE = 00 (TMA)
IFTF = 0
Motorola interface
Channel No. E
User’s Manual
109
01.2000
PEB 20320
Functional Description
Slot
Boundaries
0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0
D6 D7 AF BD 0 0 D7 D7 2 8 6 3 D7 7 D 7 8
Octet
Synchr.
TC
2 Octet
Synchr.
TCs
Octet
Not
Synchr. Octet
TC Synchr.
TC not Filtered
Generate HI-Interrupt
8800202E
31
31
0
00040000
40040000
0
20040000
40040000
31
0
6B F5 BD 00
31
0
14 C6 BE 1E
ITD04560
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
Generate HI-Interrupt
8800202E
31
0
31
00040000
40040000
0
31
20040000
40040000
31
0
6B EB F5 BD
0
00040000
40040000
31
0
00 EB EB 14
31
0
C6 EB BE 1E
ITD04559
Figure 65
User’s Manual
110
01.2000
PEB 20320
Functional Description
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
00
BD F5 6B
for the first descriptor and
1E BE C6 14
for the second.
Example 2:
(with subchanneling)
TMA channel with
TFLAG = 00H (required because of subchanneling)
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
User’s Manual
111
01.2000
PEB 20320
Functional Description
Slot Boundaries
Fill/Mask
"one" Overwrite
111111110 100 11000 10 11000 10 11110 1
External Data
(RDATA)
000000000 1100 110 1110 100 100 10 100 1
Internal Data
00000000 11110 1111110 11110 110 10 11
For INV=1
1111111110 1110 1110 110 111110 10 110
31
0
00040000
40040000
31
0
00 EF F7 D6
ITD04558
Figure 66
User’s Manual
112
01.2000
PEB 20320
Functional Description
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 performed automatically.
Table 1
Synchronization Pattern for V.110/X.30-Frames
Octet No.
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
9
10
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
The E-, S-, X-bits are fed into the data stream by special transmit descriptor (as shown
in Figure 30), they can only change from one 10-octet frame to the next, not within a 10octet 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 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 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.
User’s Manual
113
01.2000
PEB 20320
Functional Description
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 MUNICH32 was unable to access the shared memory in time either for new
data to be sent or for a new descriptor.
(maskable by TE in the channel spec.)
User’s Manual
114
01.2000
PEB 20320
Functional Description
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
Generate HI-Interrupt
8800201F
31
0
31
00028000
20030000
0
E, S, X
0
31
0
31
0
31
0
DATA 1 XX FA D6 C3 E, S, X
0
00030000
20018000
0
31
0
1 75 40 00 00
Generate HI-Interrupt
880201F
0
31
0
2 8A 80 00 00
31
0
DATA 2 XX D1 E2 C0
ITD05037
Figure 67
Note: The first transmit descriptor must have the V.110-bit set.
User’s Manual
115
01.2000
PEB 20320
Functional Description
TRV = 00
0
1
1
1
1
1
1
1
1
1
0
1
1
1
0
0
0
0
0
0
0
1
1
1
0
1
0
0
0
0
0
1
1
1
0
0
0
0
0
0
0
1
1
1
0
1
0
0
0
0
0
1
1
0
0
1
0
0
0
0
0
1
1
0
0
1
0
0
0
0
0
0
1
0
1
0
0
1
0
1
0
1
1
1
1
1
1
1
1
1
0
0
0
1
1
0
0
0
1
0
0
0
0
1
1
1
0
0
1
0
0
0
1
1
1
0
0
1
1
0
0
0
1
1
1
1
0
1
1
0
0
0
1
1
1
1
0
1
0
0
0
0
1
1
1
1
0
1
0
0
0
0
1
0
1
0
0
1
0
1
0
1
1
1
1
1
1
1
1
1
0
0
0
1
0
0
1
1
1
1
0
0
0
1
0
1
1
1
1
1
0
0
1
1
0
0
1
1
1
1
0
0
1
1
0
1
1
1
1
1
0
0
1
0
0
1
1
1
1
1
0
0
1
0
0
1
1
1
1
1
0
0
1
0
1
0
0
1
0
1
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
1
1
0
1
0
0
1
1
1
1
1
1
1
1
1
0
0
0
1
0
1
0
0
0
1
0
0
0
1
0
0
0
0
0
1
0
0
1
1
0
1
0
0
0
1
0
0
1
1
0
0
0
0
0
1
0
0
1
0
0
0
0
0
1
1
0
0
1
0
0
0
0
0
1
1
0
1
0
1
0
1
1
0
1
0
0
1
1
1
1
1
1
1
1
1
0
1
1
0
0
1
0
0
1
0
0
1
1
0
0
0
0
0
1
0
0
1
0
0
0
1
0
1
1
0
0
1
0
0
0
0
0
1
1
0
0
1
0
0
0
0
0
1
0
0
0
1
0
0
0
0
0
1
0
0
0
1
0
1
0
1
1
0
1
0
User’s Manual
SA
X
SB
1 E1E2E3E4E5E6E7
D6 = 11 0 1 0 1 1 0
B6B5B4B3B2B1
FA = 11 1 1 1 0 1 0
B6B5B4B3B2B1
Change of E-, S-, X-bits
116
01.2000
PEB 20320
Functional Description
TRV = 01
0
1
1
1
1
1
1
1
1
1
0
1
1
0
0
0
0
1
0
1
0
1
1
0
0
1
0
1
0
1
0
1
0
0
0
0
0
1
0
0
0
1
0
0
0
1
0
1
0
0
0
1
0
0
0
1
1
1
1
0
0
1
0
0
0
1
1
1
1
0
0
0
1
0
1
0
0
1
0
1
0
1
1
1
1
1
1
1
1
1
0
0
1
1
1
0
0
0
0
0
0
0
1
1
1
1
0
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
0
1
1
1
0
0
0
0
0
1
0
1
1
1
0
0
0
0
0
1
0
1
1
1
0
0
0
0
0
0
1
0
1
0
0
1
0
1
0
1
1
1
1
1
1
1
1
1
0
0
1
0
0
1
1
0
0
1
0
0
1
0
0
0
1
0
0
1
0
0
0
0
1
1
1
0
0
0
0
0
0
0
1
0
1
0
0
0
0
1
0
0
1
0
0
0
1
0
0
1
0
0
1
0
0
0
1
0
0
1
0
1
0
1
1
0
1
0
SA
X
SB
1 E1E2E3E4E5E6E7
FA (last byte of DATA 1)→
11 1 1 1 0 1 0
B6B5B4B3B2B1
C0 (first byte of DATA 2) →
11 0 0 0 0 0 0
B6B5B4B3B2B1
Change of E-, S-, X-bits
E2 = 1 1 1 0 0 0 1 0
B6B5B4B3B2B1
D1 = 1 1 0 1 0 0 0 1
B6B5B4B3B2B1
TRV = 10
0
1
1
1
1
1
1
1
1
1
0
1
0
0
0
0
0
1
0
0
0
1
0
0
0
1
0
1
0
0
0
1
0
1
1
0
1
1
0
0
0
1
0
1
1
1
1
1
0
0
0
0
0
1
0
1
0
1
0
0
0
0
0
1
0
1
0
1
0
0
0
0
1
0
1
0
0
1
0
1
0
1
1
1
1
1
1
1
1
1
0
0
0
1
0
1
0
0
0
1
0
0
0
1
0
0
1
1
0
1
0
0
1
0
0
0
1
0
0
0
0
0
1
0
0
0
0
1
0
1
0
1
1
0
1
0
User’s Manual
SA
X
SB
1 E1E2E3E4E5E6E7
Change of E-, S-, X-bits
E2 = 1 1 1 0 0 0 1 0
B6B5B4B3B2B1
D1 = 1 1 0 1 0 0 0 1
B6B5B4B3B2B1
117
01.2000
PEB 20320
Functional Description
TRV = 11
0
1
1
1
1
1
1
1
1
1
0
1
0
0
0
0
0
1
0
1
1
1
0
1
1
0
0
0
1
0
0
0
0
0
0
0
0
1
0
1
0
0
0
0
1
1
0
1
0
1
0
0
0
1
0
1
1
0
0
0
1
0
1
0
0
1
0
1
Change of E-, S-, X-bits
For INV = 1 (channel inversion) all bits are inverted. For Motorola mode the data sections
would have to have the form to yield the same output data.
31
0
E, S, X 1 00 00 40 75
31
0
DATA 1 C3 86 FA XX
31
0
31
0
E, S, X 2 00 00 80 8A DATA 2 C0 E2 D1 XX
XX XX 00 03
ITD05038
Figure 68
User’s Manual
118
01.2000
PEB 20320
Functional Description
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 synchronism is detected.
– 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:
RESET
Unsynchronous State
8 * "0" bit followed
by a "1" bit
3 Consecutive Erroneous Frames
(with a Frame Error)
Synchronous State
ITD05039
Figure 69
Data extraction and monitoring of a change of E-, S-, X-bits and synchronization pattern
is only performed in synchronized state.
In the asynchronous state the receiver waits for the synchronization patter. The ‘1’-bit is
then interpreted as bit 1 of octet 2.
3. During the synchronized state a change 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 even if SA e.g. changes 3 times within the frame. The E-, S-, X-bits reported
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.
User’s Manual
119
01.2000
PEB 20320
Functional Description
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.
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
9
10
0
1
1
1
1
1
1
1
1
1
0
B1
B1
B2
B3
E1
B4
B4
B5
B6
0
B1
B1
B2
B3
E2
B4
B4
B5
B6
0
B1
B2
B2
B3
E3
B4
B5
B5
B6
0
B1
B2
B2
B3
E4
B4
B5
B5
B6
0
B1
B2
B3
B3
E5
B4
B5
B6
B6
0
B1
B2
B3
B3
E6
B4
B5
B6
B6
0
S1
X
S3
S4
E7
S6
X
S8
S9
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.
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
9
10
0
1
1
1
1
1
1
1
1
1
0
B1
B2
B4
B5
E1
B7
B8
B10
B11
0
B1
B2
B4
B5
E2
B7
B8
B10
B11
0
B1
B3
B4
B6
E3
B7
B9
B10
B12
0
B1
B3
B4
B6
E4
B7
B9
B10
B12
0
B2
B3
B5
B6
E5
B8
B9
B11
B12
0
B2
B3
B5
B6
E6
B8
B9
B11
B12
0
S1
X
S3
S4
E7
S6
X
S8
S9
User’s Manual
120
01.2000
PEB 20320
Functional Description
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.
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
9
10
0
1
1
1
1
1
1
1
1
1
0
B1
B4
B7
B10
E1
B13
B16
B19
B22
0
B1
B4
B7
B10
E2
B13
B16
B19
B22
0
B2
B5
B8
B11
E3
B14
B17
B20
B23
0
B2
B5
B8
B11
E4
B14
B17
B20
B23
0
B3
B6
B9
B12
E5
B15
B18
B21
B24
0
B3
B6
B9
B12
E6
B15
B18
B21
B24
0
S1
X
S3
S4
E7
S6
X
S8
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. Subchannelling with 1, 2, 4, 8 Fill/Mask
Bit Set
Octet No.
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
9
10
0
1
1
1
1
1
1
1
1
1
0
B1
B7
B13
B19
E1
B25
B31
B37
B43
0
B2
B8
B14
B20
E2
B25
B32
B36
B44
0
B3
B9
B15
B21
E3
B27
B33
B39
B45
0
B4
B10
B16
B22
E4
B29
B35
B41
B47
0
B5
B11
B17
B23
E5
B29
B35
B41
B47
0
B6
B12
B18
B24
E6
B30
B36
B42
B48
0
S1
X
S3
S4
E7
S6
X
S8
S9
They are grouped together 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 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 first 10-octet frame, B7 to B12 belong
to the second 10-octet frame etc.
User’s Manual
121
01.2000
PEB 20320
Functional Description
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 the second occurrence of X within the 10octet 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 HOLD bit in the receive descriptor was detected (this leads 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
User’s Manual
122
01.2000
PEB 20320
Functional Description
... 0 0 0 0
0
1
1
1
1
1
1
1
1
1
0
0
0
1
1
1
1
1
0
1
0
0
1
1
1
1
1
1
1
0
0
0
0
1
0
0
1
1
1
1
0
0
1
0
0
1
1
1
0
1
0
0
1
1
1
0
1
0
0
0
0
0
0
1
0
0
1
0
1
1
0
0
0
0
1
1
1
1
1
0
0
1
1
1
1
1
1
1
1
1
0
0
0
1
0
1
1
1
0
0
0
0
0
1
0
1
1
1
0
0
0
0
1
1
0
0
1
0
0
0
0
0
1
1
0
1
1
0
0
0
0
0
1
0
0
0
1
0
0
0
0
0
1
0
0
0
1
0
0
0
1
1
1
1
0
1
1
1
1
0
0
1
1
1
1
0
1
1
1
1
0
0
0
1
0
1
1
1
1
1
0
0
0
1
0
1
1
1
1
1
0
0
1
1
0
0
1
1
1
1
0
0
1
1
0
1
1
1
1
1
0
0
1
0
0
0
1
1
1
1
0
0
1
0
0
0
1
1
1
1
0
0
1
1
0
1
1
1
1
1
0
1
1
1
1
1
1
1
1
0
0
1
1
1
1
1
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
1
1
1
1
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
0
1
1
1
1
0
MUNICH32 waits for synchronization after reset
1 1 1 0 1 0 0 1 E9 H
B6 B5 B4 B3 B2 B1
Reported as X
Reported as SA
Reported as SB
Error in synchronization pattern
1 1 0 0 1 0 1 0 CAH
B6 B5 B4 B3 B2 B1
No change of E, S, X Bits
Change of E, S, X Bits; but SA is still reported as ’1’
1 1 1 1 1 0 1 0 FA H
B6 B5 B4 B3 B2 B1
Reported as SA
Error in synchronization pattern
1 1 0 1 0 0 1 0 D2 H
B6 B5 B4 B3 B2 B1
No change of E, S, X Bits
Error in synchronization pattern
ITS08219
Figure 70a
User’s Manual
123
01.2000
PEB 20320
Functional Description
0
1
1
1
1
1
1
1
1
0
0
0
1
0
1
1
0
1
0
1
0
0
1
0
1
1
0
1
0
1
0
0
1
0
1
0
0
1
0
1
0
0
1
0
1
1
0
1
0
1
0
0
1
0
1
0
0
1
0
1
0
0
1
0
1
0
0
1
0
1
0
1
1
1
0
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
FF H
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
FF H
Change of E, S, X Bits
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
C0 H
EDH
No change of E, S, X Bits
Error in synchronization pattern
Change of E, S, X Bits
No error in synchronization pattern
Change of E, S, X Bits
Error in synchronization pattern
ITS08220
Figure 70b
User’s Manual
124
01.2000
PEB 20320
Functional Description
8FFF002D
8F57002D
8C00002D
8800202D
8E5B002D
8E5B002D
8800022D
st
1 Desc
31
2
31
0
00080000
40042000
Loss of Synch.
nd
Desc
0
20040000
40040000
31
0
E9 CA FA D2
31
0
ED FF FF C0
ITD05040
Figure 71
For Intel mode the data sections have the form:
of 1st Desc
31
0
D2 FA CA E9
of 2 nd Desc
31
0
C0 FF FF ED
ITD05041
Figure 72
User’s Manual
125
01.2000
PEB 20320
Functional Description
2.5
Boundary Scan Unit
In MUNICH32 a Test Access Port (TAP) controller is implemented. The essential part 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.
Test Access Port
Pins
JTEST0 (TCK)
Clock
Generation
1
2
CLOCK
Reset
JTEST1 (TMS)
Test
Control
BS Data IN
TAP Controller
Control Bus
JTEST2 (TDI)
Data IN
JTEST3 (TDO)
-Finite State Machine
-Instruction Register (3 bits)
-Test Signal Generator
6
Boundary Scan (n Bits)
Power ON
Reset
Identification Scan (32 Bits)
CLOCK
ID Data OUT
Enable
SS Data OUT
n
Data OUT
ITB03509
Figure 73
Block Diagram of Test Access Port and Boundary Scan
Test handling is performed via the pins JTEST0 (TCK), JTEST1 (TMS), JTEST2 (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 boundary scan testing is planned JTEST1 (TMS) and JTEST2 (TDI) do not need to
be connected since pull-up transistors ensure high input levels in this case. Nevertheless
it would be a good practice to put the unused inputs to defined levels. In this case, if the
JTAG is not used:
JTEST1 = JTEST0 = ‘1’.
After switching on the device (VDD = 0 to 5 V) a power-on reset is generated which forces
the TAP controller into test logic reset state.
User’s Manual
126
01.2000
PEB 20320
Functional Description
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
User’s Manual
127
01.2000
PEB 20320
Functional Description
Table 6
Boundary Scan Sequence in PEB 20320 (cont’d)
JTEST2 (TDI) →
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
Pin
I/O
Number of
Boundary Scan Cells
Constant Value
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
User’s Manual
128
01.2000
PEB 20320
Functional Description
Table 6
Boundary Scan Sequence in PEB 20320 (cont’d)
JTEST2 (TDI) →
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
Pin
I/O
Number of
Boundary Scan Cells
Constant Value
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
→ 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.
User’s Manual
129
01.2000
PEB 20320
Functional Description
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 operation)
handled like BYPASS
EXTEST is used to examine the interconnection of the devices on the board. In this test
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).
Subsequently all output pins are updated according to the new boundary scan contents
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 corresponding internal line whereas all input pins are held on constant values (‘0’
or ‘1’, according 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 operation.
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’.
JTEST2 (TDI) → 0110
0000 0000 0000 0101 0000 1000 001 1
IDCODE for old versions:
→ JTEST3 (TDO)
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.
User’s Manual
130
01.2000
PEB 20320
Operational Description
3
Operational Description
3.1
Reset State
Upon reset MUNICH32 is set to its initial state. The active high system reset clears the
internal logic and causes MUNICH32 to tristate all output lines. Channel processing is
deactivated. After reset all buffers are empty and no buffer size of TB is allocated 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 RO and TO are set to ‘1’ and RA and TA are set to ‘0’ for all logical channels by
reset. All time slots are connected to the logical channel 0 and the following configuration
is set:
Action Specification
LOC = LOOP = LOOPI = 0
PCM = T1/DS1 × 24-channel 1.536 Mbit/s (000)
MFL = 0
Time Slot Assignment
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,
RO = 1
RA = 0
TO = 1
TA = 0
TH = 0
User’s Manual
131
01.2000
PEB 20320
Operational Description
Transmit Descriptor
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/IDLE state for all channels, i.e. it assumes that on the line there are ‘1’s as interframe
time-fill for HDLC.
3.2
Initialization Procedure
After reset MUNICH32 remains in the initial state until the microprocessor generates 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
prevent malfunction the initialization of the link lists and the allocation of the buffer size
to the channels has to be specified before the transmission can be started. The interrupt
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 respectively. The first rising edge of TSP/RSP should not take place within the 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 action service the device first reads the control start address in the control and
configuration section which is located under a fixed address determined by the input
signals (CI(4:0)).
The values of CI(4:0) can be changed during operation. The values are used after the
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
User’s Manual
132
01.2000
PEB 20320
Operational Description
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9
CI4
CI3
8
7
CI2
6
5
4
3
2
CI1 CI0
1
0
0 0
Figure 74
CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl.
Start Addr.
CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl.
Start Addr.
0
0
0
0
0
0000
0000
1
0
0
0
0
FFC0 0000
0
0
0
0
1
0000
0004
1
0
0
0
1
FFC0 0004
0
0
0
1
0
0000
0008
1
0
0
1
0
FFC0 0008
0
0
0
1
1
0000
000C 1
0
0
1
1
FFC0 000C
0
0
1
0
0
0000
FFF0 1
0
1
0
0
FFC0 FFF0
0
0
1
0
1
0000
FFF4 1
0
1
0
1
FFC0 FFF4
0
0
1
1
0
0000
FFF8 1
0
1
1
0
FFC0 FFF8
0
0
1
1
1
0000
FFFC 1
0
1
1
1
FFC0 FFFC
0
1
0
0
0
003F
0000
1
1
0
0
0
FFFF 0000
0
1
0
0
1
003F
0004
1
1
0
0
1
FFFF 0004
0
1
0
1
0
003F
0008
1
1
0
1
0
FFFF 0008
0
1
0
1
1
003F
000C 1
1
0
1
1
FFFF 000C
0
1
1
0
0
003F
FFF0 1
1
1
0
0
FFFF FFF0
0
1
1
0
1
003F
FFF4 1
1
1
0
1
FFFF FFF4
0
1
1
1
0
003F
FFF8 1
1
1
1
0
FFFF FFF8
0
1
1
1
1
003F
FFFC 1
1
1
1
1
FFFF FFFC
Figure 75
CI-Pin Decoding
User’s Manual
133
01.2000
PEB 20320
Detailed Register Description
4
Detailed Register Description
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.
User’s Manual
134
01.2000
PEB 20320
Detailed Register Description
CCBA
Control Start Address
Receive
DATA
Channel 0
Action Specification
Interrupt
Circular
Queue
Interrupt Queue Specification
Time Slot 0 Assignment
Receive
Descriptor
Channel 0
Time Slot 31 Assignment
Transmit
DATA
Channel 0
Receive
Descriptor
Channel 0
Channel 0 Specification
Transmit
Descriptor
Channel 0
Transmit
Descriptor
Channel 0
Channel 31 Specification
Last 8 Blocks
not used in
T1/DS1 Mode
Current Receive Descriptor
Address Channel 0
Current Receive Descriptor
Address Channel 31
Current Transmit Descriptor
Address Channel 0
Current Transmit Descriptor
Address Channel 31
Control and Configuration Section
ITD03508
Figure 76
Organization of the Shared Memory
User’s Manual
135
01.2000
PEB 20320
Detailed Register Description
4.2
Control and Configuration Section
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
4.2.1
Action Specification (Read Once After Each Action Request Pulse)
All actions are selected by setting the corresponding bits to ‘1’.
31
30
29
28
27
26
25
24
23
22
20
19
18
17
16
4
3
2
1
0
IM RES LOC LOOP LOOPI IA
0
0
PCM
15
14
IN IC0
21
MFL
13
0
12
11
10
9
Channel Number
8
7
6
5
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 Frame Length (up 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 transparent 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 logical channels.
User’s Manual
136
01.2000
PEB 20320
Detailed Register Description
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
0
1
0
1
0
1
0
1
LOOP
0
0
0
0
1
1
1
1
LOOPI
0
0
1
1
0
0
1
1
Interpretation
no loop
not allowed
complete internal loop
channelwise internal loop
complete external loop
channelwise external loop
not allowed
not allowed
The loops have the following functions:
– Complete external loop
The serial data input is physically mirrored back to the serial data output. The time and
strobe signals for receive and transmit direction have to be identical.
– Complete internal loop
The serial data output is physically mirrored back to the serial data input. 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.
User’s Manual
137
01.2000
PEB 20320
Detailed Register Description
– 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
PCM, MFL, IM, IA
CHANNEL NUMBER
for selected loop type
don’t change the previous values
in case of channelwise loops use the selected
channel number
in case of complete loops use channel number of an
active channel.
Switch loops off:
RES = IN = ICO = ‘0’
LOC = ‘0’, LOOP = LOOPI = ‘1’
PCM, MFL, IM, IA
CHANNEL NUMBER
IA:
don’t change the previous values
use channel number used with the ‘switch loop on’.
Interrupt Attention; a new interrupt queue is defined by the host. MUNICH32 reads
the interrupt queue specification and writes the interrupt information into the new
interrupt queue.
User’s Manual
138
01.2000
PEB 20320
Detailed Register Description
IN
ICO
MFL
PCM
0
Initialization Procedure
Read the complete time-slot
assignment and the channel
spec. of the specified channel
(channel number).
Initialize Channel Only
Channel
Number
IM
RES
LOC
LOOP
LOOPI
IA
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
0 0
Channel No.
Interrupt Attention
Used in
conjunction
with IN
and ICO
A new interrupt queue
has been defined. Read
the interrupt queue
specification.
Loops
000
001
010
011
100
101
110
111
Only the channel spec.
of the selected channel
(channel number) is
read and reconfigured.
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.
No Loop
Complete Internal Loop
Complete Internal Loop
Not Allowed
Not Allowed
Channelwise int. Loop
Channelwise ext. Loop
Not Allowed
Reset
Read the complete time-slot assignment
Read all channel specifications
Reinitialize all time-slots
PCM Highway Format
000
001
010
011
100
101
110
111
Interrupt Mask
T1/DS1 24 Time-Slots, 1.536 Mbit/s
Not Allowed
Not Allowed
Not Allowed
T1/DS1 24 Time-Slots, 1.544 Mbit/s
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
Do not generate the ARACK & ARF interrupt
ITS08221
Figure 77
Action Specification
User’s Manual
139
01.2000
PEB 20320
Detailed Register Description
4.2.2
Interrupt Queue Specification
31
30
29
28
27
26
25
24
23
22
0
0
0
0
0
0
0
0
0
0
15
14
13
12
11
10
9
8
7
6
0
0
0
0
0
0
21
20
19
18
17
16
0
0
0
0
0
0
5
4
3
2
1
0
Interrupt Queue Address
Interrupt Queue Address
0
0
n
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 Section.
overwrite
START ADDRESS
(Interrupt Queue
Address)
interrupt information long word 1
interrupt information long word 2
interrupt information long word 3
length =
(n + 1) × 16 long words
where 0 ≤ n ≤ 255
.
.
.
interrupt information long word (n+1)x16
Figure 78
The minimum queue size is 16 long words; the maximum queue size is 4096 long words.
For each interrupt arising, the MUNICH32 writes the interrupt information into the
interrupt queue, will increment the pointer to the next address in this block automatically
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 interrupt queue, it will jump to the start address of the interrupt block again
(cyclic queue) and completely overwrite the previous information.
Therefore the length of the interrupt queue should be calculated so, that the MUNICH32
will not overwrite information which was not yet read by the processor.
User’s Manual
140
01.2000
PEB 20320
Detailed Register Description
4.2.3
Interrupt Information
The next table shows the bit assignments for the interrupt information long word.
31
30
INT
0
15
14
29
28
27
26
25
24
23
22
21
20
19
18
17
16
4
3
2
1
0
Interrupt Information
13
12
11
10
9
8
7
6
Interrupt Information
5
Channel Number/Direction
When an interrupt occurs MUNICH32 sets 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 channel in one direction are treated independently of each other. If several interrupt
events coincide they will be indicated to the host with one shared interrupt.
31
30
INT
0
15
14
29
28
27
26
VN3 VN2 VN1 FRC
25
24
E7
E6 E5 E4 E3 E2 E1 SB SA
13
12
11
10
9
8
ARACK ARF HI
FI
IFC
SF ERR FO
23
22
21
7
6
5
0
0
RT
20
4
19
3
18 17 16
2
1
X
0
Channel Number
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
User’s Manual
141
01.2000
PEB 20320
Detailed Register Description
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 cannot be performed. An action request 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 interrupt 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 transmit direction indicated 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 following table shows which interrupts can occur in which mode (unused bits are
always 0).
31
30
INT
0
29
28
27
26
VN3 VN2 VN1 FRC
HDLC
1
0
V.110/X.30
1
0
TMA
1
0
TMB/TMR
1
0
25
24
23
22
21
20
19
18
17
16
E7
E6
E5
E4
E3
E2
E1
SB SA
X
F
F
F
0
0
0
0
0
0
0
0
0
0
0
F
F
F
R
R
R
R
R
R
R
R
R
R
R
F
F
F
0
0
0
0
0
0
0
0
0
0
0
F
F
F
0
0
0
0
0
0
0
0
0
0
0
15
14
13
12
11
10
9
8
7
6
5
ARACK
ARF
HI
FI
IFC
SF
ERR
FO
0
0
RT
HDLC
G
G
V.110/X.30
G
G
TMA
G
G
TMB/TMR
G
G
User’s Manual
4
3
2
1
0
Channel Number
TR
TR R
R
TR
TR 0
0
X
X
X
X
X
X
TR
0
0
0
TR
TR 0
0
X
X
X
X
X
X
TR
T
0
0
TR
TR 0
0
X
X
X
X
X
X
TR
TR 0
0
TR
TR 0
0
X
X
X
X
X
X
142
01.2000
PEB 20320
Detailed Register Description
Where ‘1’
‘0’
‘F’
‘R’
means that the bit is always ‘1’ for this mode
means that the bit is always ‘0’ for this mode
means the bit is fixed by the version number
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 there
is more than one change within the frame. After detecting a receive 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
User’s Manual
143
01.2000
PEB 20320
Detailed Register Description
new frame, or when it starts polling the hold bit if set in conjunction with
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 interframe time-fill (ITF) state. 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 without shared zeroes. It changes back to the ITF idle state
upon reception of 15 contiguous ‘1’-bits or when a receive abort channel
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 detected. The sequences 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
User’s Manual
144
01.2000
PEB 20320
Detailed Register Description
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
see Chapter 1.2
Transmit Direction
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 buffer overflow 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
see 1.2
FO:
Transmit Direction
1.1 HDLC, TMB, TMR
Receive Direction
The MUNICH32 has discarded one or more whole frames or short
User’s Manual
145
01.2000
PEB 20320
Detailed Register Description
frames or change of interframe time-fill 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 be accessed before the Tx-FO or BERR happened
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 inaccessibility 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 Direction
The MUNICH32 has discarded data due to inaccessibility of the internal
buffer RB.
3.2 see Chapter 1.2
The following table shows which interrupt bits are masked by which bits in the channel
specification.
31
30
INT
∅
29
28
27
26
VN3 VN2 VN1 FRC
25
24
23
22
21
20
19
18
17
16
E7 E6 E5 E4 E3 E2 E1
SB
SA
X
2
1
0
Receive
CH
–
Transmit
15
14
13
12
11
10
9
8
ARACK ARF HI
FI
IFC
SF ERR FO
7
6
5
0
0
RT
4
3
Channel Number
Receive
FIR IFC SFE RE
RE
FIT
TE
Transmit
User’s Manual
–
–
TE
146
01.2000
PEB 20320
Detailed Register Description
General
IM
IM
0 0
3
4
2
1
0
Channel
Number
RT
0 VN(3...1)
FRC
E7
E6
E5
E4
E3
E2
E1
SB
SA
X
ARACK
ARF
HI
FI
IFC
SF
ERR
F0
INT
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
Framing Bits Changed
Channel Number
V.110/X30 mode
received E, S, X Bits changed
Identifies the channel
where the interrupt
occured.
Action Request Acknowledge
Direction
Action request has been
completed successfully.
0 Transmit Interrupt
1 Receive Interrupt
Action Request Failed
Action request could not be
completed successfully.
Overflow/Underflow
Internal buffer not available
Silicon Version Number
Protocol Error
000
001
010
100
e.g. CRC error, frame aborted,
loss of sync. MFL exceeded
Internal buffer overflow/underflow
V1.1
V2.1
V2.2
V3.2
Short Frame
Host Initiated Interrupt
HI Bit in the Rcv./Xmt. descriptor was set
HDLC mode, in conjunction with FI
(empty HDLC frame or incorrect HDLC frame,
nothing stored in memory)
Frame Indication Interframe Timefill Change
End of receive or transmit frame indication HDLC receiver detected change in ITF state
Valid Interrupt Entry
MUNICH32 sets this Bit with every entry
to the interrupt circular queue
Software should dear this Bit after reading
ITS08222
Figure 79
Interrupt Information
User’s Manual
147
01.2000
PEB 20320
Detailed Register Description
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 assignment provides the cross reference between the 32 (24) time slots 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 Mbit/s per channel.
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
Transmit Fill Mask
time slot 31
15 14 13 12 11 10
9
8
7
6
5
4
3
2
1
0
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
Fill/Mask Code:
User’s Manual
For bit rate adaption the fill/mask code determines the number of bits
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).
148
01.2000
PEB 20320
Detailed Register Description
Channel Number: The channel number identifies the data channel. Its transmission
mode is described in the respective channel specification.
TTI:
Transmit Time slot Inhibit; setting this 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 only once after each activation request pulse with an action specification with set
IN, RES or ICO bit; RES: the channel specifications of all channels; IN, IC0: the channel
specification of the channel indicated in the action specification)
31
30
29
28
27
26
25
24
23
Interrupt Mask
22
21
20
19
18
17
16
NITBS RI
TI
TO
TA
TH RO RA
0
0
0
0
0
0
3
2
1
0
FRDA
FTDA
0
0
0
0
0
0
15 14 13 12 11 10
0
0
9
0
8
0
7
6
TFLAG TFLAG
/NSF
/CS
INV
TFLAG
CR
C
5
4
TRV
FA
Mode
IFT
F
FRDA
FTDA
0
0
0
0
0
0
0
0
0
0
ITBS
Interrupt Mask:
7
6
5
4
3
2
1
0
–
SFE
IFC
CH
TE
RE
FIR
FIT
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).
User’s Manual
149
01.2000
PEB 20320
Detailed Register Description
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 value; if this bit is set the individual transmit buffer size ITBS is valid
and a new buffer field of TB is assigned to the channel. In this process first the
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
(occupied by other channels) the process will be aborted and an action request
failure interrupt is generated. After aborting no buffer size is allocated to the
channel. For preventing action request failure enough buffer locations 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 conjunction with a transmit abort channel command.
The bits RI, TI, TO, TA, TH, RO, RA are the so called channel command bits. They allow
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 previous receive abort or receive off condition, affects
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 previous receive abort or receive off condition, affects
only the DMA interface)
This abort is performed in the DMA controller and does not interfere with the reception
on the serial interface and the transfer of the data into the receive buffer. If this abort
is detected the current receive descriptor is suspended with an abort status (RA bit set
User’s Manual
150
01.2000
PEB 20320
Detailed Register Description
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, TMR (V.110/X.30, TMA) mode the device waits for a new frame (10octet frame, nothing) to begin and then starts filling RB again. If the receive off
command lead to an improper finishing of a frame (data, 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 receive off condition by a receive initialization command.
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 bits only or to an interrupt with set SF, FI and ERR bits. If the receiver was
User’s Manual
151
01.2000
PEB 20320
Detailed Register Description
•
•
•
•
in the flag interframe time-fill state it will lead to an interrupt with set 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 descriptor. It will also issue an interrupt with set ERR bit and (unless
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 advisable to clear the receive abort condition via a receive off command 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
condition during at least 16, 240, 16, 32, 8 bits of the channel for HDLC, V.110/
X.30, TMB, TMR, TMA respectively.
– receive jump
RI = 1, RO = 0, RA = 0 (clears a previous receive abort or receive off condition, affects
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 controller will proceed finishing the current receive descriptor as usual either
with a frame end condition or with the corresponding data buffer completely filled 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 previous receive abort or receive off condition, affects
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 current receive descriptor is suspended without writing the second long word 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
User’s Manual
152
01.2000
PEB 20320
Detailed Register Description
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 channel having a time 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 changing 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 receive clear command if neither a receive off nor a receive abort condition is set
– 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 transmit abort or transmit off condition, affects
only the serial interface)
• if the channel was never initialized by a transmit initialization command it has no
effect
• if it was initialized previously it clears a transmit off or transmit abort condition set by
a previous channel command
• 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 transmit abort or transmit off condition, affects
only the DMA interface)
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 and the frame or data transferred
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.
User’s Manual
153
01.2000
PEB 20320
Detailed Register Description
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 00H
for TMB
at least 00 00H for 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 transmit buffer is not accessed for this channel. The output time slots are tristated.
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 descriptor 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 descriptor.
• In TMA mode the device starts with the interframe time-fill
TFLAG
for FA = 1
for FA = 0
FFH
and then with the data in the descriptor at the FTDA.
User’s Manual
154
01.2000
PEB 20320
Detailed Register Description
– 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
for TMB
00H
for TMR
0000H
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 transmit abort the TF does not access the transmit buffer. The handling of the
link list is not affected by the transmit abort, i.e. the device keeps the TB full. When the
transmit abort is withdrawn the transmit formatter continues the transmission with the
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 be reinitialized by a transmit initialization command together
with the revoking of the transmission abort.
Another proper use of the transmit abort command consists in setting the last
descriptor of the last frame to be transmitted with HOLD = 1 and waiting for the device
to poll the HOLD bit (ITBS + 2) times where ITBS is the number of long words
assigned to this channel currently. Afterwards TB is empty and the transmit abort then
issued does not abort a currently sent frame. The same procedure can also be used
for the transmit off command.
– 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 during normal operation. Then MUNICH32 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 controller will proceed finishing the current transmit descriptor as usual and
afterwards branch to the new descriptor specified by FTDA. If the current descriptor
does not include a frame end (FE = 0) (HDLC, TMB, TMR) the DMA controller will link
the following data section(s) of the ‘new’ descriptor chain to the opened frame. This
may generate unexpected frames.
User’s Manual
155
01.2000
PEB 20320
Detailed Register Description
– transmit initialization
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 the channel. This command should therefore be the first channel
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 case the transmit initialize command should be accompanied by the NITBS
bit set and a reasonable 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
3 frames 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 characters
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 supposed to be used it should be issued a transmit initialization 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
User’s Manual
156
01.2000
PEB 20320
Detailed Register Description
4.
5.
6.
7.
8.
9.
10.
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.
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.
To revive a channel after it has been shut down one should use the transmit
initialization command.
For V.110/X.30-mode the first descriptor after reviving from shut down or initialization
after reset must have the V.110-bit set and contain the E-, S-, X-bits.
To switch to a new starting point of a transmit descriptor chain one should preferably
use the transmit jump command, only exceptionally the fast transmit abort command
and never the transmit initialize command.
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.
Bit combinations in the first transmit command group not described are reserved.
Set NITBS = 1 preferably in conjunction with a transmit initialize and transmit clear
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.
User’s Manual
157
01.2000
PEB 20320
Detailed Register Description
Receive Frame Examples:
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 or 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 transmit 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 inverted.
CRC:
Cyclic Redundancy Check; in HDLC mode this bit determines the
CRC generator 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’.
User’s Manual
158
01.2000
PEB 20320
Detailed Register Description
TRV:
Transmission Rate of V.110/X.30. These signals determine the number of
repeated D-bits in a V.110/X.30 frame.
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
Note: In the other modes these bits must be set to ‘00’.
FA:
Flag Adjustment selected (in HDLC mode) or flag filtering (selected in
transparent mode A only if all fill/mask bits of the corresponding slots are ‘1’).
In all other modes this bit must be set to ‘0’. If flag adjustment is selected in
HDLC mode the number of interframe time-fill characters is FNUM minus one
eighth of the number of zero insertions in the frame proceeding the interframe
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 specified in TFLAG is recognized and extracted from the data stream.
In transmit direction the flag TFLAG is sent in all exception conditions, i.e.
abort, idle state etc.; if flag filtering is not selected ‘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: Transparent mode A
01: Transparent mode B or transparent mode R.
IFTF:
Interframe Time-Fill: this bit determines the interframe
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 channel command.
User’s Manual
159
time-fill for
01.2000
PEB 20320
Detailed Register Description
FTDA:
First Transmit Descriptor Address points to the beginning of the transmit data
chaining list.
This descriptor is only interpreted with a fast transmit abort or a transmit 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
formatting and transmitting. The individual buffer size 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).
Mode
IFTF
TRV
FA
TFLAG
CS
INV
CRC
0
SFE
IFC
CH
TE
RE
FIR
FIT
NITBS
RI
TI
TO
TA
TH
RO
RA
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
FRDA (First Receive Descriptor Address)
FTDA (First Transmit Descriptor Address)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ITBS (buffer size)
New ITBS Value Rcv./Xmt. Commands Transparent Mode Flags
Interframe
Rcv. Commands
Timefill
New Xmt. buffer size
Fill code for flags in
0 7E (flags)
(ITBS valid) (RI, RO, RA):
transp. mode A (TMA only)
000 Rcv. Clear
1 FF (ones)
001 Fast Rcv. Abort
(HDLC mode)
Interrupt Mask
CRC Select
010 Rcv. OFF
SFR: Short Frame (R)
CRC Generated/Stripped 0
011 Rcv. Abort
Mode
CRC to/from Data Section 1
IFC: Idle/Flag Change (R)
100 Rcv. Jump
(HDLC mode only)
CH: V.110 Frg. Chg. (R)
0 0 TMA
101 Rcv. Init.
TE: ERR Interrupt (T)
0 1 TMB/TMR
110 Not Allowed
RE: ERR Interrupt (R)
1 0 V.110/X30
Inversion
111 Not Allowed
FIR: FI Interrupt (R)
1 1 HDLC Mode
All
Rcv.
and
Xmt.
data
Bits
FIT: FI Interrupt (T)
First Xmt. Commands
in this channel are inverted.
(R) Receiver Interrupt
Flag Adjustment/Filtering
(T) Transmitter Interrupt
(TI, TO, TA):
FNUM interframe timefill
CRC Polynom
000 Xmt. Clear
characters in HDLC mode,
001 Fast Xmt. Abort
16 Bit CRC (HDLC mode) 0
or TFLAG filtering in TMA
010 Xmt. OFF
32 Bit CRC (HDLC mode) 1
011 Xmt. Abort
TMB 0
100 Xmt. Jump
TMR 1 Transmission Rate of V.110/X30
101 Xmt. Init.
0 0 600 bit/s, 7 Repetitions
110 Not Allowed
0 1 1200 bit/s, 3 Repetitions
111 Not Allowed
1 0 2400 bit/s, 1 Repetitions
1 1 4.8, 9.6, 19.2, 38.4 kbit/s,
2 nd Xmt. Commands
no Repetition
(TH = 1) : Xmt. Hold
ITS08223
Figure 80
Channel Specification
User’s Manual
160
01.2000
PEB 20320
Detailed Register Description
4.2.6
Current Receive and Transmit Descriptor Address
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
For easier monitoring of the link lists the addresses of the just processed descriptors are
written into the CCS. MUNICH32 changes the current descriptor address at the same
time when it branches to the next descriptor.
User’s Manual
161
01.2000
PEB 20320
Detailed Register Description
4.3
31
Transmit Descriptor
30
29
28
27
26
25
24
23
FE HOLD HI
22
21
20
19
18
17
16
4
3
2
1
0
NO
Transmit Data Pointer
Next Transmit Descriptor Pointer
15
14
13
12
11
V.110
0
0
0
CSM
10
9
8
7
6
5
FNUM
Transmit Data Pointer
Next Transmit Descriptor Pointer
FE:
Frame End; this bit is valid in all modes.
It indicates that after sending the data in the transmit data section
– the device generates an interrupt with FI bit set for HDLC, TMB, TMR, TMA
ERR bit set for V.110/X.30
– the device then sends
for HDLC, IFTF = 0
• (FNUM + 1) × 7EH
• 7E, (FNUM – 1) × FFH, 7E for HDLC, IFTF = 1, FNUM ≥ 1
• 7E
for HDLC, IFTF = 1, FNUM = 0
for TMB, TMR (FNUM ≥ 1)
• (FNUM + 1) × 00H
• 000H
for TMR, FNUM = 0
• (FNUM + 1) × TFLAG
for TMA, FA = 1
for TMA, FA = 0
• (FNUM +1) × FFH
• three frames with synchronization errors for V.110/X.30
before starting with the data of the next transmit descriptor. If the
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.
User’s Manual
162
01.2000
PEB 20320
Detailed Register Description
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
for HDLC, IFTF = 0
• (FNUM + 1) × 7EH
for HDLC, IFTF = 1
• 7E, FNUM × FFH
for TMB, TMR (FNUM ≥ 1)
• (FNUM + 1) × 00H
• 0000H
for TMR, FNUM = 0
• (FNUM + 1) × TFLAG
for TMA, FA = 1
for TMA, FA = 0
• (FNUM + 1) × FFH
• 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 sends interframe time-fill until 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 byte number defines the number of bytes stored in the data section 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 following 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 this bit set if it revives the channel from a transmit off condition or
after a pulse at the reset pin.
User’s Manual
163
01.2000
PEB 20320
Detailed Register Description
Intel Mode
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
E7
E6
E5
E4
E3
E2
E1
SB
SA
X
0
0
0
0
0
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Motorola Mode
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
SA
X
0
0
0
0
0
0
E7
E6
E5
E4
E3
E2
E1
SB
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 means that after the current frame only 1 character (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, TFLAG, TFLAG for TMA, 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 7EH FFH 7EH (IFTF = 1) for HDLC and 00H 00H 00H for TMB and
TMR, TFLAG, TFLAG, TFLAG for TMA, FA = 1; FF FF FFH for TMA, FA = 0)
are sent.
User’s Manual
164
01.2000
PEB 20320
Detailed Register Description
FNUM = k means that after the current frame k + 1 characters are sent
for ITFT = 0 and HDLC
(k + 1) times 7EH
7EH, (k – 1) times FFH, 7EH
for ITFT = 1 and HDLC
for TMB, TMR
(k + 1) times 00H
(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.
Transmit Data Pointer: This 32-bit pointer contains the start address of the transmit data
section. Although MUNICH32 works only long word oriented, it
is possible to begin a transmit data section at an uneven
address. The two least significant 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.
ADD:
00 = 4 bytes
01 = 3 bytes
10 = 2 bytes
11 = 1 byte
MUNICH32 reads the first long word and discards the unused
least significant bytes. The NO establishes (determines) 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.
User’s Manual
165
01.2000
PEB 20320
Detailed Register Description
For example (Intel mode):
1) ADD = 01, NO = 8
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
2) ADD = 00, NO = 8
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
–
3) ADD = 10, NO = 1
11
10
01
00
–
byte 0
–
–
–
–
–
–
–
–
–
–
1 long word is read!
For example (Motorola-mode):
1) ADD = 01, NO = 8
11
–
10
01
00
byte 0 byte 1
byte 2
byte 3 byte 4 byte 5
byte 6
byte 7
–
–
3 long words are read
–
2) ADD = 00, NO = 8
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
3) ADD = 10, NO = 1
11
–
User’s Manual
10
–
01
byte 0
166
00
–
1 long word is read!
01.2000
PEB 20320
Detailed Register Description
Next Transmit
Descriptor Pointer:
This 32-bit pointer contains the start address of the next transmit
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 HOLD bit. In this case FTDA is used as a pointer for
the next transmit descriptor to be branched to.
User’s Manual
167
01.2000
PEB 20320
Detailed Register Description
4.4
Receive Descriptor
31
30
29
28
27
26
25
24
23
22
0
HOLD
HI
NO
FE
C
0
BNO
21
20
19
18
17
16
5
4
3
2
1
0
Receive Data Pointer
Next Receive Descriptor Pointer
15
14
13
0
0
0
12
11
10
9
8
0
0
0
0
0
Status
7
6
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Receive Data Pointer
Next Receive Descriptor Pointer
The receive descriptor contains 4 long words; the first, third and fourth 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 interrupt with set FI bit is generated, and in case 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
User’s Manual
168
01.2000
PEB 20320
Detailed Register Description
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 number defines the size of the receive data section allocated 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 greatest 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:
Receive Descriptor
Receive Data Section
00000000.00001000.00000000.00000
XX.XX.XX.data
11000000.00000001.Status.00000000
receive data pointer
next receive descriptor pointer
The data bytes are stored into the receive data section according to the 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 that a receive frame 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 the 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 ⇒ status = 02
User’s Manual
169
01.2000
PEB 20320
Detailed Register Description
• 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:
MUNICH32 writes the number of data bytes it has stored in the current data
section into BNO.
Status:
The MUNICH32 writes the status information into the status byte whenever 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.
7
6
5
4
3
2
1
0
0
SF
LOSS
CRCO
NOB
LFD
RA
ROF
HDLC CS = 0
0
NI
0
ILN
IL
I
I
I
HDLC CS = 1
0
0
0
ILN
IL
I
I
I
V.110/X.30
0
0
I
0
0
0
IF
I
TMB
0
0
0
0
IL
I
IF
I
TMR
0
0
0
0
IL
I
IF
I
TMA
0
0
0
0
0
0
IF
0
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.
User’s Manual
170
01.2000
PEB 20320
Detailed Register Description
NI
means the bit may be ‘1’ or ‘0’ but does not cause an interrupt with
set ERR bit.
ILN
means that it may be ‘1’ or ‘0’ but should 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 it may be ‘1’ only after a fast receive abort channel command
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 detected CRCO = 0 means the frame had
no CRC error.
NOB = 1
A frame whose bit content was not divisible by 8 was detected.
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 detected and aborted. The reception will be continued 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.
User’s Manual
171
01.2000
PEB 20320
Detailed Register Description
Note: In case of multiple errors all relevant bits are set.
In case of ROF = 1 only the error conditions of the frame within which the overflow
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.
User’s Manual
172
01.2000
PEB 20320
Application Notes
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 subdivided into channelwise and complete test loops thus
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.
CD
1
&
RDATA
RSP
RCLK
µP Interface
TSP
TCLK
Enable Int.
Complete Loop
&
TDATA
ITS08198
Figure 81
User’s Manual
173
01.2000
PEB 20320
Application Notes
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.
CD
1
µP Interface
Channel X only
RDATA
&
Enable Int.
Channelwise Loop
for Channel X
TDATA
ITS08199
Figure 82
5.1.1.3 External Complete Test Loop
The serial data input is physically routed to the serial data output. Data is received 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.
User’s Manual
174
01.2000
PEB 20320
Application Notes
CD
RDATA
&
RSP
RCLK
Enable Ext.
Complete Loop
µP Interface
TSP
TCLK
&
1
TDATA
ITS08200
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
capabilities during idle channel time slots, without interfering with normal data reception/
transmission.
CD
RDATA
Channel X only
µP Interface
Enable Ext.
Channelwise Loop
for Channel X
&
1
TDATA
ITS08201
Figure 84
User’s Manual
175
01.2000
PEB 20320
Application Notes
5.1.2
Test Loop Activation
All of the test loops are closed (activated) and opened (deactivated) by setting/resetting
the appropriate combination of bits in the Action Specification (Table 10). Any unlisted
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 pin to ‘1’, there are exceptions to this rule. Generally, the test loops can be opened
by software. There are several cases that must be examined and these will be discussed
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.
Table 10
Test Loop Activation
Test Loop
LOC
LOOP
LOOPI
ASP
Internal complete
0
0
1
xxxxxx08H
Internal channelwise
1
0
1
xxxxxx28H
External complete
0
1
0
xxxxxx10H
External channelwise
1
1
0
xxxxxx30H
No loop
0
0
0
xxxxxx00H
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
deactivate a test loop a new ASP should be issued with LOC, 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.
User’s Manual
176
01.2000
PEB 20320
Application Notes
5.1.3.1 Software Operations
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 Reset Operations
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
Complete Loop
Internal
Channelwise
Loop
X
HDW Reset
required
Internal
Channelwise
Loop
External
Complete
Loop
External
Channelwise
Loop
SFW
HDW Reset
required
HDW Reset
required
HDW Reset
required
HDW Reset
required
X
External
HDW Reset
Complete Loop required
HDW Reset
required
External
Channelwise
Loop
HDW Reset
required
User’s Manual
HDW Reset
required
177
X
HDW Reset
required
SFW
X
01.2000
PEB 20320
Application Notes
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-8004
;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
NxtRDPtr
→
32 byte
data block
0020-0000
0000-0000
RcvDtaPtr
NxtRDPtr
→
32 byte
data block
0020-0000
0000-0000
RcvDtaPtr
NxtRDPtr
→
32 byte
data block
+

+→
+

+→
+

+→
FTDA:
+

+→
+

+→
User’s Manual
4020-0000
0000-0000
RcvDtaPtr
0000-0000
;HOLD = 1
→
32 byte
data block
;
HOLD, FE = 1 for dummy frame
0020-0000
XmtDtaPtr
NxtTDPtr
→
abcdefghijklmnop
qrstuvwxyz012345
C020-0000
XmtDtaPtr
0000-0000
→
C000-0000
XmtDtaPtr
NxtTDPtr
178
;FE, HOLD = 1
ABCDEFGHIJKLMNOP
QRSTUVWXYZ987654
01.2000
PEB 20320
Application Notes
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)
;Polls HOLD bit of 1st Tx Desc.
9000-1000
Set ASP for Internal Channelwise Loop test
ASP:
A104-0028
;CEPT, MFL=260, Int. Chnl loop
Generate AR Pulse and wait for INT signal.
Read interrupt queue:
ICQ:
9000-8000
9000-1000
9000-082020
;Action Request Acknowledge
;Polls HOLD bit of 1st Tx Desc.
;Rc ITF state change
Clear HOLD bit in FTDA (allow frame to Tx over Internal Chnl. Loop).
Read interrupt queue:
ICQ:
9000-1000
;End of Tx frame, polling HOLD
bit of Tx desc.
;Rc frame complete
9000-1020
Read receive descriptors:
FRDA:
0020-0000
4020-0000
RcvDtaPtr
+ NxtRDPtr

+→ 0020-0000
4020-0000
RcvDtaPtr
+ NxtRDPtr

+→ 0020-0000
C000-0000
RcvDtaPtr
+

+→
User’s Manual
→
;C = 1, NO = BNO
abcdefghijklmnop
qrstuvwxyz012345
→
;C = 1, NO=BNO
ABCDEFGHIJKLMNOP
QRSTUVWXYZ987654
→
;FE, C = 1, BNO = 0
;empty! (p. 139 User’s Manual FE description)
NxtRDPtr
4020-0000
0000-0000
RcvDtaPtr
0000-0000
→
179
32 byte
data block
01.2000
PEB 20320
Application Notes
5.1.4.2 External Channelwise Test Loop
Generate HW RESET, and hold off RSP/TSP for 1000 SCLK cycles.
ASP:
IQS:
TSA[0]:
TSA[1…31]:
CSP[0]:
CSP[1…31]
CRA[0…31]
CTA[0…31]
A104-8004
ICQ
0000-001F
00FF-00FF
0000-0000 (×31)
00E9-0006
FRDA
FTDA
0000-0002
0000-0000 0000-0000
0000-0000 (×32)
0000-0000 (×32)
;CEPT, MFL=260, IN, IA=1
;TS0 = CH0
;Tx/Rc init, poll Tx desc., HDLC
;ITBS = 2 long words
0000-0000 0000-0000 (x31)
ICQ:
0000-0000 (×512)
FRDA:
0020-0000
0000-0000
RcvDtaPtr
NxtRDPtr
+

+→
+

+→
+

+→
FTDA:
User’s Manual
+→

+
0020-0000
0000-0000
RcvDtaPtr
NxtRDPtr
0020-0000
0000-0000
RcvDtaPtr
NxtRDPtr
4020-0000
0000-0000
RcvDtaPtr
0000-0000
→
32 byte
data block
→
32 byte
data block
→
32 byte
data block
;HOLD = 1
→
C000-0000
XmtDtaPtr
NxtTDPtr
32 byte
data block
;HOLD, FE = 1 for dummy frame
180
01.2000
PEB 20320
Application Notes
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)
;Polls HOLD bit of 1st Tx Desc.
;FI Frame indication for the
1st Tx Desc.
;Now M32 starts polling HOLD
bit of 1st Desc.
9000-1000
9000-1000
Set ASP for External Channelwise test loop
ASP:
A104-0030
;CEPT, MFL=260, Ext. Chnl loop
Generate AR Pulse and wait for INT signal.
Read interrupt queue:
ICQ:
9000-8000
9000-0820
;Action Request Acknowledge
;Only if other station uses
idle code 7E
;Received frame complete
9000-1020
Read receive descriptors: ;assumes 64 byte frame externally looped
FRDA:
0020-0000
;with proper HDLC 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 byte
0000-0000
data block
User’s Manual
181
01.2000
PEB 20320
Application Notes
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.
LAN
Router
ISDN
Router
LAN
ITS08283
Figure 85
ISDN/LAN Router
The structure of the whole system is shown in Figure 85. The router itself is realized as
a stand alone solution. It is connected to a standard PC for software download and
maintenance control only. After the download the system works fully independent of the
host 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
explained as far as necessary to understand this special application. It is suggested that
the reader has some knowledge about the MUNICH32 before reading this application
note. Detailed information about the MUNICH32, its features and memory structures are
given in the MUNICH32 PEB20320 Data Sheet.
User’s Manual
182
01.2000
PEB 20320
Application Notes
5.2.2
Hardware
The processor system is based on a Motorola 68040 processor. It contains 512 KByte
SRAM, a bus controller and peripherals like timer, EPROM and interrupt controller. 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.
ISDN
Interface
LAN
Interface
RS232
Timer
EPROM
MC68040
Interrupt
Controller
SRAM
Bus
Controller
Alternate
Busmaster
Connector
Peripheral
Connector
Glue Logic
i82596
MUNICH32
i82C501
ACFA
EM 2
PRACT
LAN
Connector
ISDN
Connector
ITB08284
Figure 86
Hardware Block Diagram
User’s Manual
183
01.2000
PEB 20320
Application Notes
Application Specific Hardware
The application specific hardware consists of an ISDN primary rate interface and an
Ethernet interface. The MUNICH32 PEB 20320 in conjunction with the layer 1 SIEMENS
components ACFA (Advanced CMOS Frame Aligner) PEB 2035 and PRACT (Primary
Rate Access Clock Generator 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 MUNICH32 with clock signals. Main task of the ACFA is the frame alignment.
Besides, the ACFA translates the dual rail data in a single rail, unipolar bit stream which
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.
Dual Rail
Unipolar
Signals
PCM
Highway
µP Interface
Overvoltage
Line IN
MUNICH32
ACFA
PRACT
Line OUT
ITS08285
Figure 87
ISDN Interface
The Ethemet interface is built with a LAN controller, a Manchester encoder/decoder and
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 processing the transmit data is Manchester encoded and forwarded to the
transmission line, while receive data is Manchester decoded before being processed by
the LAN controller.
User’s Manual
184
01.2000
PEB 20320
Application Notes
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 is done via the shared memory. The CPU informs 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.
Control
Signals
MUNICH32
Control
Signals
CPU
i82596
Shared
Memory
Local Bus
ITS08286
Figure 88
System Architecture
User’s Manual
185
01.2000
PEB 20320
Application Notes
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
arbiter. The bus arbitration protocol is also Motorola specific. The intel specific signals 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
mastership the arbiter 2 gives a bus request to the arbiter 1. Arbiter 1 forces the CPU to
release the bus and gives bus mastership to arbiter 2. Arbiter 2 then responds to
MUNICH32 or LAN controller. In this solution the priority of the 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
controller 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.
Arbiter 2
Arbiter 1
MUNICH32
CPU
i82596
ITS08287
Figure 89
Bus Arbitration
User’s Manual
186
01.2000
PEB 20320
Application Notes
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
MUNICH32 bus timing needs to be adapted by using simple glue logic. One Gate Array
Logic (Gal16V8, 15 ns) contains all necessary logic.
The MUNICH32 Address Strobe (AS) signal determines valid addresses 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 used to generate the
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.
BCLK
SCLK
TS
TA
Addr
Data
AS
DSACK
ITD08288
Figure 90
MUNICH32 Timing Adaption
1)
See also Chapter 5.2.6.
User’s Manual
187
01.2000
PEB 20320
Application Notes
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
signals for the LAN controller, that have to be generated. Furthermore the 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 Entry points offer access to the DDMs. Messages can be sent to the DDM via the
Message Entry Point. A hardware interrupt causes the program to branch 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.
Device Driver System
Message
Message
Device Driver Module
Application Module
Interrupt
Hardware
ITS08289
Figure 91
Module Entry Points
User’s Manual
188
01.2000
PEB 20320
Application Notes
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. The Module Init Routine is called by the DDS. Additionally 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
detailed information about the other DDS service routines please refer to the SIPB 7520
Primary Rate User Board or EASY532 Datacom Userboard Documentation.
Memory Management
With the memory management functions the allocation of message descriptors,
MUNICH32 receive/transmit descriptors1) or LAN controller receive/transmit descriptors
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 descriptor 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
functions available to convert the descriptor type.
1)
Refer to MUNICH32 Data Sheet.
User’s Manual
189
01.2000
PEB 20320
Application Notes
Message Descriptor Pool
Allocate
Free
MUNICH32/LAN Controller
Descriptor Pool
Convert
Allocate
Free
ITS08290
Figure 92
Memory Management
User’s Manual
190
01.2000
PEB 20320
Application Notes
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
initialized, all time-slots are initialized, ACTION
REQUEST Pulse is generated.
ConfigMunich32
Sets PCM mode and maximum frame length, 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.
SendFrame
Adds tx descriptors to the transmit descriptor queue and
clears hoId bit of poll descriptor if the channel is active.
TxJump
If no poll descriptor is detected Initialize Channel Only 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
Initialize Channel Only bit is set, turns channel 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.
User’s Manual
191
01.2000
PEB 20320
Application Notes
Function
Action
TxShutDown
Initialize Channel Only bit is set, gives ‘transmit off’
command or ‘transmit abort’ command, ACTION
REQUEST Pulse is generated.
RcJump
Initialize Channel Only bit is set, If last command was
‘transmit off’ or ‘transmit abort’ ‘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.
ShowMunich32VersionNr
ACTION REQUEST Pulse is generated.
CheckActionRequestQueue Looks for messages to be processed and branches to
the Message Entry Point.
Interrupt Entry Point
The information in the interrupt queue is read and a message containing that information
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.
User’s Manual
192
01.2000
PEB 20320
Application Notes
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 channel once. Transmit data is then added to the memory structures by 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 32channel 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 MUNICH32 is alerted to access all time-slot assignments and the channel
specification by setting the in-bit.
The fillmask (transmit and receive) for the selected channel is written in the appropriate
word of the time-slot assignment. All other channels and their fillmasks are not affected.
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-bits are set to zero. For that reason the MUNICH32 does not transmit anything 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
structures. The hold bit of the last descriptor in the list is set to indicate the end of the list.
In all other descriptors the hold bit is cleared.
User’s Manual
193
01.2000
PEB 20320
Application Notes
Send Frame Routine
Calling ‘SendFrame’ after initialization of a channel results in executing ‘AddHdlcFrame’.
In that routine the transmit descriptors are disconnected from the message and linked to
the memory structures. If the message source is the ‘MROUTE Application Module’ the
hold bit and fe-bit indicating the end of a frame and the end of the list have already been
set/cleared in the MROUTE module, they are not modified anymore. If the message
source is any other module the fe-bit and hold bit are cleared in all descriptors except for
the last one. There the hold bit has to be set, to prevent the MUNICH32 from branching
to the next descriptor. Setting the fe-bit in the last descriptor only forces the MUNICH32
to send the data in one HDLC frame. The bits HI, V110 and CSM are cleared in both
cases.
Transmit/Receive Interrupt
A transmit acknowledge interrupt is treated by returning the transmit descriptor(s) to the
descriptor pool.
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
structures. An equivalent number of new descriptors is allocated and linked 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 devices the MUNICH32 and the LAN controller organize receive and transmit data
in a linked list of receive descriptors and a linked list of transmit descriptors. 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. On the other hand to take the LAN controller’s receive descriptor and link it to the
MUNlCH32’s transmit descriptor queue.
User’s Manual
194
01.2000
PEB 20320
Application Notes
ISDN
64 kbit/s
each Channel
LAN
max 10 Mbit/s
fe = SET
Ch1
Frame Descr
Count Count
EOF = 0
fe = SET
0
Frame Descr
Count Count
EOF = 1
2
EOF = SET
fe = SET
0
Ch 2
Frame Descr
Count Count
EOF = 1
1
2
1
ITS08291
Figure 93
Insertion of additional Information
To make efficient use of the available bandwidth, the parallel use of several B-channels
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
necessary. The frame is then sent via the ISDN by using a separate B-channel for every
LAN receive descriptor. To ensure that the parts of the Ethernet frame will be
reassembled in correct order, every part of the Ethernet frame is supplied with additional
information. That additional information has to be extracted before reassembling the
frame. In Figure 93 an example of one Ethernet frame consisting of three descriptors,
spread over two B-channels, is shown. The additional information contains the frame
number, the descriptor number and the information, whether the frame is completed. To
simplify the extraction of the additional information every frame part and its additional
information are sent in one HDLC frame.
User’s Manual
195
01.2000
PEB 20320
Application Notes
The fe-bit marks the end of one HDLC frame, the EOF bit marks the end of the Ethernet
frame. The additional information comprises the 8-bit word descriptor count, 16-bit word
frame count and EOF a 8-bit variable which indicates the last descriptor of the frame.
Message Entry Point
The message entry point calls two functions: IsdnRouteFrame and LanRouteFrame. An
Ethernet frame is processed by IsdnRouteFrame, an ISDN frame by LanRouteFrame.
The MUNICH32 receive descriptors are converted to LAN controller transmit descriptors
and those of the LAN controller are converted to MUNICH32 transmit descriptors.
MROUTE Module
LAN Route Frame
ISDN Route Frame
Message Descr
Message Descr
LAN Controller
TX Descr
MUNICH32
RC Descr
LAN Controller
RC Descr
MUNICH32
TX Descr
MUNICH32
DDM
LAN Controller
DDM
ITS08292
Figure 94
Message Flow between DDMs and MROUTE Module
Besides the IsdnRouteFrame realizes the insertion of additional information and splits
an Ethernet frame on several B-channels. The additional information is stored in an extra
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
descriptor and than processed from the LAN controller DDM.
User’s Manual
196
01.2000
PEB 20320
Application Notes
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 MUNICH32 poll access’ influence on the data rate. Finally the processing of one
frame is illustrated.
Data Rates
The data rate during transmission from the ISDN into the Ethernet was tested.
kbit/s
2000
1800
1600
1400
1200
1000
800
600
400
200
0
Data Rate available
Data Rate without
MUNICH32 polling
Data Rate with MUNICH32
polling
Channels
0
3
6
9
12
15
18
21
24
27
30
ITD08293
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
decreases. This shows the influence of the MUNICH32 polling the Hold bit.
User’s Manual
197
01.2000
PEB 20320
Application Notes
Bus Occupancy
The bus occupancy during normal operation is shown in Figure 96. In this case the data
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
because of inserted wait states in every bus cycle. Another reason is the bus controller’s
clock which is switched from 33 MHz to 40 MHz. This and the existence of two alternate
bus masters results in a more time consuming arbitration protocol than that needed for
a simpler architecture.
i82596
M32 5 %
5%
CPU
90 %
ITD08294
Figure 96
Bus Occupancy
1)
Compare Data Sheet.
User’s Manual
198
01.2000
PEB 20320
Application Notes
MUNICH32 Polling
The influence of the polling can be illustrated by showing the bus occupancy of
MUNICH32 poll accesses only.
M32
17 %
Idle
10 %
CPU
73 %
ITD08295
Figure 97
Bus Occupancy During Polling
Here the MUNICH32 is polling 31 channels (= 31 × 2 read accesses during 125 µs).
Every access is 5 clock cycles long, instead of the minimum length of 4 clock cycles. The
time for the arbitration protocol needed during every access results in bus idle time.
User’s Manual
199
01.2000
PEB 20320
Application Notes
Frame Processing
During normal operation the processing of a frame comprises three consecutive parts.
During transmission from ISDN to LAN the frame is first processed from the MUNICH32,
then from the CPU and finally from the LAN controller.
Frame 1
Frame 2
MUNICH32
CPU
i82596
t
ITD08296
Figure 98
Frame Processing
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.
User’s Manual
200
01.2000
PEB 20320
Application Notes
5.2.5
Final Remarks
This application note shows a design example for the MUNICH32 (PEB 20320). Though
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
potential because of its modular structure. Additionally the existence of the 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 influence of MUNICH32 poll accesses is extremely high in this example, because of
the bus arbitration architecture and the system 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.
User’s Manual
201
01.2000
PEB 20320
Application Notes
MROUTE Module
LAN Route Frame
ISDN Route Frame
Upper Layer
Software
Upper Layer
Software
Message Descr
Message Descr
LAN Controller
TX Descr
MUNICH32
RC Descr
LAN Controller
RC Descr
MUNICH32
TX Descr
MUNICH32
DDM
LAN Controller
DDM
ITS08297
Figure 99
Integration of Upper Layer Software
User’s Manual
202
01.2000
PEB 20320
Application Notes
5.2.6
Adaption of the 68040 µP Signals
begin header
This GAL is used to adapt the 68040 µ-processor signals to the 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
M32ASQ
reset
M32BGACKQ
int
ACREQM68
RWQ
clk
rclk
= 1,
= 2,
= 3,
= 4,
= 5,
= 6,
= 7,
= 8,
= 9;
feedback (com)
DSACKQ
= 19;
output (com)
TSQ
RESETQ
INTQ
ACREQM32
sclk
= 18,
= 17,
= 16,
= 15,
= 14;
statebits
sb2
sb1
= 13,
= 12;
state_names
idle
one
two
= 2,
= 1,
= 0;
{= musclk}
end definition
User’s Manual
203
01.2000
PEB 20320
Application Notes
begin equations
TSQ.OE
TSQ
RESETQ
INTQ
ACREQM32
sclk
= /M32BGACKQ;
= /(/M32ASQ × DSACKQ);
= /reset;
= int;
= /(/ACREQM68 × reset × /RWQ);
= (/reset × rclk) + (reset × /clk);
end equations
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
User’s Manual
204
01.2000
PEB 20320
Application Notes
5.2.7
Schematics
LAN Interface
SER_INT
Ctrl
BRQ
BGACKQ
BGQ
A
D
MUBRQ
MUBGACKQ
MUBGOQ
MUBGQ
SERINT.SCH
LAN_CONT.SCH
ISDN
MUBGQ
MUBGOQ
MUBGACKQ
MUBRQ
Ctrl
A
D
BGQ
BGACKQ
BRQ
EASY320.SCH
ITS08298
Figure 100
User’s Manual
205
01.2000
PEB 20320
Application Notes
ACFA_PRACT
MUNICH32
PCLK3
RTCLK
TRSP
RDATA
TDATA
PCLK3
CLK2M
FSCQ
RDO
XDI
P1
LIN1
FSQ
LIN2
LOUT1
LOUT2
JP1
GND
3
1
2
SYNC
CLK4M
CLK2M
XCLK
MUNICH32.SCH
ACFAPRAC.SCH
GND
VCC
1
14
2
15
3
16
4
17
5
18
6
19
7
20
8
21
9
22
10
23
11
24
12
25
13
CONNECTOR DB25
Female
ITS08299
Figure 101
User’s Manual
206
01.2000
PEB 20320
Application Notes
J1C
J1A
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
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
A31
A30
A29
A28
A27
A26
A25
A24
A23
A22
A21
A20
A19
A18
A17
A16
A15
A14
A13
A12
A11
A10
A9
A8
A7
A6
A5
A4
A3
A2
U1
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
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
D31
D30
D29
D28
D27
D26
D25
D24
D23
D22
D21
D20
D19
D18
D17
D16
D15
D14
D13
D12
D11
D10
D9
D8
D7
D6
D5
D4
D3
D2
D1
D0
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A15
A16
A17
A18
A19
A20
A21
A22
A23
A24
A25
A26
A27
A28
A29
A30
A31
VG96
VG96
D0
D1
D2
D3
D4
D5
D6
D7
D8
D9
D10
D11
D12
D13
D14
D15
D16
D17
D18
D19
D20
D21
D22
D23
D24
D25
D26
D27
D28
D29
D30
D31
J1B
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
64
63
62
61
60
59
58
57
56
55
54
53
52
51
50
49
48
47
46
45
44
43
42
41
40
39
38
37
36
35
34
33
MUSCLK
BBQ
BCLK
TSQ
BGQ
LOCKQ
M32BGQ
BGACKQ
WRQ
PCSQ5
VCC
GND
JP 2
1
ADDWSQ
2
CRSTQ
MUINTQ
PCLK3
VG96
100
96
94
91
102
107
109
114
116
120
122
126
128
133
135
139
143
147
149
154
156
160
2
6
8
13
15
19
21
26
28
33
35
39
BE0
BE 1
BE 2
BE 3
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A15
A16
A17
A18
A19
A20
A21
A22
A23
A24
A25
A26
A27
A28
A29
A30
A31
95
99
101
106
108
113
115
119
121
125
127
132
134
138
142
146
148
153
155
159
1
5
7
12
14
18
20
25
27
32
34
38
90
85
86
75
76
74
82
79
81
80
66
40
I/M
D0
D1
CI 0
D2
CI 1
D3
CI 2
D4
CI 3
D5
CI 4
D6
D7
TEST
D8
D9
D10
D11
D12 JTEST 0
D13 JTEST 1
D14 JTEST 2
D15 JTEST 3
D16
D17
RESET
D18
SCLK
D19
D20
D21
D22
D23
D24
D25
D26
D27
D28
D29
D30
D31
W,R/R,W
ADS/AS
DS
READY/DSACK
BERR
B16
HOLD/BR
HLDA/BG
PM
HLDAO/BGO
AR
INT/INT
RTCLK
TRSP
RDATA
TDATA
PCLK3
M32BGQ
U8
GND
OE
CLK
RCLK
RSP
RDATA
TCLK
TSP
TSP
44
45
46
69
68
67
12
13
14
15
16
17
18
19
M32BGQ
Ι8
Ι7
Ι6
Ι5
Ι4
Ι3
Ι2
Ι1
O8
O7
O6
O5
O4
O3
O2
O1
11
BCLK
9
8
7
6
5
4
3
2
GAL16V8
BGACKQ
BRQ
LOCKQ
BBQ
CRSTQ
BGACKQ
BRQ
BGQ
RP1
1
2
3
4
5
6
7
8
73
47
48
49
50
51
65
16
15
14
13
12
11
10
9
VCC
4.7 k Ω
MUBGACKQ
U7
OE
CLK
GND
12
13
14
15
16
17
18
19
53
54
55
56
60
61
DSACKQ
Ι8
Ι7
Ι6
Ι5
Ι4
Ι3
Ι2
Ι1
O8
O7
O6
O5
O4
O3
O2
O1
GAL16V8
VCC
11
9
8
7
6
5
4
3
2
GND
MUSCLK
RWQ
PCSQ5
INT
MUBGACKQ
CRSTQ
ASQ
TSQ
MUINTQ
R1
MUBRQ
3.3 k Ω
MUNICH32
MUBGOQ
MUBGQ
VCC
GND
C1
100 nF
C2
100 nF
C3
100 nF
C4
100 nF
C5
100 nF
C6
100 nF
C7
100 nF
C8
100 nF
C9
100 nF
C 10
100 nF
C 11
100 nF
C 12
100 nF
C 13
100 nF
C 14
100 nF
ITS08300
Figure 102
User’s Manual
207
01.2000
PEB 20320
Application Notes
ADR3
ADR2
ADR1
ADR0
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
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
J2A
VG96
U10
LOOP
RSTQ
RDO
AD0
AD1
AD2
AD4
AD5
VCC
D1
LED Red
XDI
R2
1kΩ
1
VCC
22
33
11
JP 3
GXDI
COS
U3
PCSQ2 46 CE
FRDQ 22 RD
FRDQ 25 WR
INTQ2
5 AINT
36 ACKNL
ADR0 18 A0
ADR1 19 A1
ADR2 20 A2
ADR3 21 A3
27 COS
RDO
4 RDO
34 XDI
VCC
R4
10 k Ω
AD0
AD 1
AD 2
AD 3
AD 4
AD 5
AD 6
AD 7
33
8
39
40
6
37
9
10
11
12
13
14
15
16
ROID
XOID
RSIGM
XSIGM
RCHPY
XCHPY
D0
D1
D2
D3
D4
D5
D6
D7
XTOM
XTOP
XDOM
XDOP
RDIM
RDIP
XRCLK
RRCLK
3
44
43
42
31
30
41
29
SCLK
28
Ι1
Ι2
Ι3
Ι4
Ι5
Ι6
Ι7
Ι8
19
18
17
16
15
14
13
12
O1
O2
O3
O4
O5
O6
O7
O8
PCSQ2
G0
G1
G2
G4
G5
GXDI
G6
1 CLK
11 OE
GAL16V8
GND
2
U2A
74HC04
R3
4.7 k Ω
2
3
4
5
6
7
8
9
CLK2MQ
XCLK
CLK4MQ
CLK2M
FSC
7
30
31
37
36
38
39
40
4
RFSP 7
SYP 32
32
28
29
RES 35
2
1
3
JP4
D2
1N4148
U2B
ACFA
3
R5
1 MΩ
C15
47 nF
4
74HC04
R6
1kΩ
D3
LED
Green
GND
VCC
GND
ITS08301
Figure 103
User’s Manual
208
01.2000
PEB 20320
Application Notes
2
3
4
5
6
7
8
9
RSTQ
PCSQ3
WRQ
AD 0
AD 1
AD 2
AD 3
AD 4
PCLK3
O1
O2
O3
O4
O5
O6
O7
O8
19
18
17
16
15
14
13
12
FRDQ
VCC
2.2 k Ω
XDI
RDO
SYNC
CLK2M
CLK2MQ
CLK4MQ
FSC
FSCQ
XCLK
CLK33_CON
LOOP
PCLK3
GAL16V8
GND
C25
47 µF
C24
47 nF
VCC
35
41
23
22
34
42
19
18
1
VSSD
VSSR
VSSX
VSSX
VDDD
VDDR
VDDX
VDDX
VDD2
D5
R7
R9
U5 1
XL 1
XL 2
RL 1
RL 2
R8
D6
JATT
SYNC
MODE
LL
LR
LS 2
LS 1
LS 0
CS
XTAL 4
XTAL 3
XTAL 2
XTAL 1
PRACT
5
20
24
44
2
15 k Ω
D7
VCC
GND
GND
VCC
D8
R
2.2 k Ω
C18
12 pF
100 nF
R12
VCC
LIN1
1kΩ
8
5
1
F5
SO5K130
R13
6
10
ZKB_402/512
F3
A81_C90X
2
1
1kΩ
LIN2
F4
A81_C90X
D11
2
X1
12 MHz
VCC
GND
C22
10 pF
C23
JATT
SYNC
MODE
G4
G5
G2
G1
G0
C21
10 pF
R11
60 k Ω
R11
60 k Ω
D10
F2
A81_C90X
2
GND
C19
LOUT2
1
1kΩ
GND
43
17
27
3
26
14
11
8
C17
12 pF
6
10
ZKB_402/512
F1
A81_C90X
2
R14
3 U6 1
VCC
1
F6
SO5K130
D9
C26
LOUT1
1kΩ
8
C16
C20
3
15 k Ω
33
9
10
12
13
FSC
FSC
XDIN
XDIP
RDON
RDOP
RCLK
CLK2M
CLK2M
CLK4M
CLK4M
CLK12M
CLK16M
XCLK
XTIN
XTIP
VCC
GND
D4
X2
16 MHz
G6
WRQ
R15
MODE
JATT
COS
LP
U4
6
7
30
31
37
36
38
39
40
4
5
16
15
32
28
29
VCC
1 CLK
11 OE
GND
CLK2MQ
XCLK
CLK4MQ
CLK2M
FSC
FSCQ
Ι1
Ι2
Ι3
Ι4
Ι5
Ι6
Ι7
Ι8
GND
PCSQ4
PCSQ3
PCSQ2
RSTQ
AD7
AD6
AD5
AD 4
AD 3
AD2
AD 1
AD 0
U9
PCSQ2
G0
G1
G2
G4
G5
GXDI
G6
INTQ2
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
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
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
J2B
VG96
J2C
VG96
VCC
GND
GND
GND
C28
100 nF
C29
100 nF
C30
100 nF
C31
100 nF
ITS08302
Figure 104
User’s Manual
209
01.2000
PEB 20320
Application Notes
U
Data
U
18
16
14
12
9
7
5
3
CLK33
TSP_OUT
PCLK3
TCLK_OUT
CLK33_CON
14
15
16
17
18
19
20
21
25
26
27
28
29
30
31
32
35
36
37
38
39
40
41
42
43
46
47
48
50
51
52
53
33 MHz
1 Y1
1 Y2
1 Y3
1 Y4
2 Y1
2 Y2
2 Y3
2 Y4
1A 1
1A 2
1A 3
1A 4
2 A1
2A 2
2A 3
2A 4
2
4
6
8
11
13
15
17
8 PHI
OSZI
TSP_IN
1G 1
2G 19
74HCT244
TCLK_IN
GND
D0
D1
D2
D3
D4
D5
D6
D7
D8
D9
D 10
D 11
D 12
D 13
D 14
D 15
D 16
D 17
D 18
D 19
D 20
D 21
D 22
D 23
D 24
D 25
D 26
D 27
D 28
D 29
D 30
D 31
124 ADS
ADSQ
65
129
130
9
123
118
69
VCC
VCC
RDTQ
HOLD
RLDA
L_RESET
VCC
2.7 k Ω
LE/BE
BS 16
RDY
CLK2
HOLD
HLDA
RESET
3.3 k Ω
GND
125 INT/INT
3 PORT
119 CA
MUINTQ
PORTQ
CA
VCC
RP1
16
15
14
13
12
11
10
9
RP2
1
2
3
4
5
6
7
8
4.7 k Ω
16
15
14
13
12
11
10
9
RDTQ
MU_BGOQ
L_LOCKQ
CPURSTQ
LAN_W_RQ
ADSQ
GND
82596DX
1
2
3
4
5
6
7
8
2.7 k Ω
HOLD
BE 0
BE 1
BE 2
BE 3
A2
A3
A4
A5
A6
A7
A8
A9
A 10
A 11
A 12
A 13
A 14
A 15
A 16
A 17
A 18
A 19
A 20
A 21
A 22
A 23
A 24
A 25
A 26
A 27
A 28
A 29
A 30
A 31
W/R
LOCK
BREQ
BE
114
113
112
109
108
107
106
105
104
103
102
101
97
96
95
94
93
92
91
90
87
85
84
83
82
81
80
79
76
74
73
72
71
70
120
126
115
ADDR
LAN_W_RQ
L_LOCKQ
GND
LPBK 58
CDT
CRS
RXD
RXC
TXD
TXC
RTS
CTS
R
VCC
Resistor
61
63
60
59
54
64
57
62
SER_INT
GND
4.7 k Ω
1
GND
9
8
7
6
5
4
3
2
RAPACK
ITS08303
Figure 105
User’s Manual
210
01.2000
PEB 20320
Application Notes
RESET
2
3
4
5
6
7
8
9
MUCLK
CPURSTQ
Ι1
Ι2
Ι3
Ι4
Ι5
Ι6
Ι7
Ι8
O1
O2
O3
O4
O5
O6
O7
O8
19
18
17
16
15
14
13
12
Address
BE
1 CLK
11 OE
GND
L_RESET
GAL16V8A
2
3
4
5
6
7
8
9
GND
MUCLK
DTOEQ
LAN_CSQ
R_WQ
M32_ARQ
CPURSTQ
Ι1
Ι2
Ι3
Ι4
Ι5
Ι6
Ι7
Ι8
O1
O2
O3
O4
O5
O6
O7
O8
19
18
17
16
15
14
13
12
GND
HLDAIN
CLK33
Ι1
Ι2
Ι3
Ι4
Ι5
Ι6
Ι7
Ι8
O1
O2
O3
O4
O5
O6
O7
O8
A1
A0
SIZ1
LAN_CSQ
M32_CSQ
SIZ0
Arbiter 2
MUCLK
CPURSTQ
Signal
ADSQ
LAN_W_RQ
TAQ
19
18
17
16
15
14
13
12
GAL16V8A
2
3
4
5
6
7
8
9
MU_BRQ
HOLD
ML_BGQ
MU_BGACKQ
19
18
17
16
15
14
13
12
O1
O2
O3
O4
O5
O6
O7
O8
M32_ARQ
GAL16V8A
2
3
4
5
6
7
8
9
Ι1
Ι2
Ι3
Ι4
Ι5
Ι6
Ι7
Ι8
1 CLK
11 OE
PORTQ
CA
1 CLK
11 OE
GND
BEQ0
BEQ1
BEQ2
BEQ3
ML_BGQ
MU_BGACKQ
A4
Port
CLK33
PCSQ5
2
3
4
5
6
7
8
9
RDYQ
R_WQ
TSQ
CLK33
Ι1
Ι2
Ι3
Ι4
Ι5
Ι6
Ι7
Ι8
O1
O2
O3
O4
O5
O6
O7
O8
19
18
17
16
15
14
13
12
BRQ
BGACKQ
HLDAIN
MU_BGQ
1 CLK
11 OE
GND
GAL16V8A
1 CLK
11 OE
GND
ITS08310
GAL16V8A
Figure 106
User’s Manual
211
01.2000
PEB 20320
Application Notes
Data
J1C
Address
J1A
J1B
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
VG96
D0
D1
D2
D3
D4
D5
D6
D7
D8
D9
D 10
D 11
D 12
D 13
D 14
D 15
D 16
D 17
D 18
D 19
D 20
D 21
D 22
D 23
D 24
D 25
D 26
D 27
D 28
D 29
D 30
D 31
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
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
PCLK3
DTOEQ
TAQ
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
MUINTQ0
CPURSTQ
MUINTQ
GND
VCC
PCSQ5
W_RQ
BGACKQ
ML_BGQ
LOCKQ
BGQ_68
TSQ
BCLK
BBQ
MUCLK
VG96
VG96
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
A 10
A 11
A 12
A 13
A 14
A 15
A 16
A 17
A 18
A 19
A 20
A 21
A 22
A 23
A 24
A 25
A 26
A 27
A 28
A 29
A 30
A 31
ITS08311
Figure 107
User’s Manual
212
01.2000
PEB 20320
Application Notes
GND
R
78 Ω
SERINT
R
78 Ω
R
240 Ω
R
240 Ω
U
TXD
TXCQ
RTSQ
17 TXD
16 TXC
15 TEN
RXD
RXCQ
CRSQ
CDTQ
C CAP
9
8
6
7
1
RXD
RXC
CRS
CDT
ENETV1
CLSN
CLSN
RCV
RCV
TRMT
TRMT
2 NOOR
3 LPBK/WDTD
LPBKQ
1
2
3
4
5
6
12
11
4
5
19
18
X1 14
X2 13
UA
2
O4
J
BNC
HBE 16
Y
1
R
D
150 Ω
LED Yellow
GND
GND
2
3
GND
JP
JUMPER3X1
EM2
20 MHz
C
30 pF
C
0.01 µF
CDS 20
RXI 18
TXO 17
CD+
CDRX+
RXTX+
TX-
VEE 11
DM 12
82C50TAD
1
GND
R
1 MΩ
U
VCC
C
30 pF
GND
U
10
VCC
C k105
R
40 k Ω
CEXT
11 REXT/CEXT
9 RIN
3
4
5
A1
A2
B
Q 6
Q 1
T21
R
D
150 Ω
LED Green
R
D
150 Ω
LED Red
GND
U
10
VCC
C k105
R
40 k Ω
CEXT
11 REXT/CEXT
9 RIN
3
4
5
A1
A2
B
Q 6
Q 1
VCC
ITS08312
T21
Figure 108
User’s Manual
213
01.2000
PEB 20320
Application Notes
5.3
Memory Bus Occupancy for a Single MUNICH32
The MUNICH32 may be used in different system architectures depending 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
coupled with a 32-bit CPU (compatible to either Motorola 68020 or Intel 386) sharing one
common local CPU bus and translated via an appropriate system bus controller sharing
the system memory as well. This example system looks very similar to the one depicted
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 arbitration time is estimated to be about 4 extra clock cycles (SCLK) for every
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 descriptors
– 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 data size exceeds 32 bytes, more than one descriptor is needed for a single
frame
– an interrupt information is generated for every descriptor.
The MUNICH32 needs the following 32-bit memory accesses (read or write):
Receive:
User’s Manual
read descriptor
write current descriptor address
write status
write interrupt
write data (size)
214
→3
→1
→1
→1
→ accesses size
1
1
1
2
1
3
1
4
2
5
:
:
01.2000
PEB 20320
Application Notes
Transmit:
read descriptor
write current descriptor address
write interrupt
read data (size)
→3
→1
→1
→ accesses size
1
1
1
2
1
3
1
4
2
5
:
:
The accumulated access time for a single MUNICH32 channel, depending on the actual
frame size, is then related to the serial transfer time on a PCM system:
(3 + size) × 125 µs.
The following two diagrams illustrate the overall results for two different ranges and 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% only and it is therefore not necessary to use a complex multiport memory
approach to reach a significant overall performance gain.
Memory Bus Occuppancy
25
Ch=32
Ch=30
Ch= 1
%
20
15
10
5
0
1
32
64
96
128 160 192 224 256 288 320 352 384 416 448 480 512
Number of Data Bytes
ITD04696
Figure 109
Frame Size 1 to 512
User’s Manual
215
01.2000
PEB 20320
Application Notes
Memory Bus Occuppancy
25
Ch=32
Ch=30
Ch= 1
%
20
15
10
5
0
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
Number of Data Bytes
ITD04697
Figure 110
Frame Size 1 to 32
User’s Manual
216
01.2000
PEB 20320
Application Notes
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
previously described, a set of equations can be used to describe the MUNICH32 system
bus behavior. Other MUNICH32 systems can be evaluated using these equations. The
Bus occupancy is defined as the ratio of the time required for memory accesses for that
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
information to/from memory.
= {([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 transmit channels.
(1 + 1/ba) is the bus arbitration time
sclk is the system clock (61 ns for 16.384 MHz)
NC is the number of memory clocks per bus operation (0ws = 4, 1WS = 5, etc.).
Time used to send the data is the number of transmitted bits per time slot multiplied 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
Value
m
rc
tc
(1 + 1/ba) sclk
NC
abtc
32 bytes 7
32
32
1.1
4
8
User’s Manual
217
61 ns
01.2000
PEB 20320
Application Notes
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 packet size is much larger (256 bytes or larger), the bus occupancy decreases
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 per packet.
5.3.2
Bus Occupancy for Idle Tx Channels
The previous discussion shows bus occupancy to be very low, even when a MUNICH32
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 characters can be determined, the MUNICH32 can be programmed
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.
User’s Manual
218
01.2000
PEB 20320
Application Notes
3. The final method is to set the HOLD bit in the Tx descriptor. When the HOLD bit in the
Tx descriptor is set, the MUNICH32 checks the status of the this bit for each time slot
assigned to this channel. In this way, if the bit has been cleared, the MUNICH32 will
immediately resume transmission. Although this method is simpler (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 slots (typical).
User’s Manual
219
01.2000
PEB 20320
Application Hints
6
Application Hints
6.1
Frequency Adaption in an Intel 368 Common Bus System
If you use the i386 as host processor with the MUNICH32 in a common bus system you
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 i386 with a frequency of 16.384 MHz. The MUNICH32 is configured 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 signal. A general bus controller should not see a difference 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.
User’s Manual
220
01.2000
PEB 20320
Application Hints
S1
S2
MUNICH32
SCLK=16.384 MHz
SCLK
ADS
READY
T1
T1
T2
T2
T1
i386, 16.384 MHz
=>CLK2=2xSCLK
CLK2
CLK
ADS
READY
Delay
ITD04556
Figure 111
User’s Manual
221
01.2000
PEB 20320
Application Hints
S1
S2
MUNICH32
SCLK=16.384 MHz
SCLK
ADS
READY
T1
T1
T1
T1
T2
T2
T1
i386, 24.576 MHz
=>CLK2=3xSCLK
CLK2
CLK
ADS
READY
Delay
ITD04557
Figure 112
User’s Manual
222
01.2000
PEB 20320
Application Hints
6.2
MUNICH32 Memory Space Requirement
Implementation independent:
–
–
–
–
Start Address
4 byte
Control & Configuration Section 908 byte
Tx Descriptor Size
12 byte
Rc Descriptor Size
16 byte
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 Descriptor Size + Data Buffer Size)] +
number of channels × [number of Rc Descriptors × (Rc Descriptor Size + Data Buffer Size)]
–––––––––––––––––––––––––––––––––––––––––––––
= Total MUNICH32 Memory Space 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 Descriptors must be available for each channel. The Data Buffer Size is set 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.
User’s Manual
223
01.2000
PEB 20320
Application Hints
6.3
Serial Interface to different PCM Systems
The serial interface of the MUNICH32 is very general and comprises standard clock,
PCM frame synchronization and data signals, which are independent for both directions.
The following description explains typical applications integrating the MUNICH32 into
2.048 Mbps PCM systems, like SIEMENS System Interface for Primary Access 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).
RCLK=TCLK
TSP
TDATA
Time-Slot 0
RSP
RDATA
Time-Slot 0
ITD04694
Figure 113
The RSP pulse is shifted by one clock period against the TSP pulse. The main task using
this timing for different PCM systems is to adapt the TSP and RSP pulses appropriately,
as described below.
6.3.1
MUNICH32 for SIEMENS Primary Access Interface
The SIEMENS devices for the Primary Access Interface is the Frame and Line Interface
Component (FALC54). This device can directly be connected to the MUNICH32 without
any additional glue logic. In combination with the MUNICH32 this application 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.
User’s Manual
224
01.2000
PEB 20320
Application Hints
TCLK
TSP
TDATA
SYPXQ
XDI
SCLKX
FALC54
PEB 2254
MUNICH32
PEB 20320
SCLKR
RDO
SYPRQ
RDATA
RSP
RCLK
CLKX CLK8M FSCQ FSC
ITS07370
Figure 114
The adaption of the TSP and RSP pulses is solved by means of shifting the receive data
and transmit data in the FALC54 device appropriately. In this case the TSP and RSP
synchronization pulses are also identical. The FALC54 device contains special registers
to control the bit shift of the serial bit streams at the system interface (see FALC54 Data
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
XC0.XCO = 06H
RDO: RC1.RTO = 00H
RC0.RCO = 05H
User’s Manual
=> X = 494
=> T = 509
=> X = 5
=> T = – 1
225
01.2000
PEB 20320
Application Hints
The timing in principle is depicted in the following diagram. Without all details of a typical
electrical timing it illustrates how the different signals from MUNICH32, and FALC54 are
mapped in such a Primary Access system.
FSC=TSP=RSP
CLKX=RCLK=TCLK
TDATA
=XDI (T=509)
RDATA
=RDO (T=-1)
ITD08282
= : Invalid area
= : Channel 0, Bit 0 (Least Significant Bit)
Figure 115
User’s Manual
226
01.2000
PEB 20320
Application Hints
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 assumption made here is that the clock master is the ST BUS system.
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
synchronization signal. The RSP pulse can be derived from the F0 signal by means 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.
TCLK
TSP
TDATA
STi
MUNICH32
PEB 20320
ST-BUS
STo
RDATA
RSP
RCLK
C2
F0
Decode
’254’
Q
&
Q
D
RES
8-Bit
Counter
Q
Q
D
System Clock Adaption
ITS04692
Figure 116
User’s Manual
227
01.2000
PEB 20320
Application Hints
The TSP pulse must be derived from the F0 signal with a phase shift by 255 clock cycles
to be at the right position. The corresponding timing is illustrated in the following diagram.
C2
F0
TSP
*)
RSP *)
RCLK=TCLK=C2
TDATA
=STi
RDATA
=STo
ITD04693
= : Invalid area
= : Channel 0, Bit 0 (Least Significant Bit)
*)
Derived from F0 and synchronized by means of C2
Figure 117
User’s Manual
228
01.2000
PEB 20320
Electrical Characteristics
7
Electrical Characteristics
Note: All specifications are for V3.4 unless otherwise specified. Version numbers are
identified in the Interrupt Information 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
Table 12
Parameter
Ambient temperature under bias: PEB
PEF
Storage temperature
Voltage at any pin with respect to ground
Symbol
TA
TA
Tstg
VS
Limit Values
Unit
min.
max.
0
– 40
70
85
°C
– 65
125
°C
– 0.4
VDD + 0.4
V
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.
User’s Manual
229
01.2000
PEB 20320
Electrical Characteristics
7.2
DC Characteristics
Table 13
TA = 0 to + 70 °C; VDD = 5 V ± 5%, VSS = 0 V
Parameter
Symbol
L-input voltage
H-input voltage
L-output voltage
VIL
VIH
VQL
Limit Values
Unit Test Condition
min.
max.
– 0.4
0.8
V
–
2.0
VDD + 0.4 V
–
–
0.45
IQL = 7 mA
V
(pin TDATA)
IQL = 2 mA
(all others)
H-output voltage
VQH
VDD – 0.5 –
V
IQH = – 2 mA
(pin HOLD/BR)
IQH = – 100 µA
(all others)
VQH
ICC
2.4
–
< 100
mA
power down
(no clocks)
ICC
–
<2
mA
Input leakage current
Output leakage current
ILI
ILQ
–
10
µA
H-output voltage
Power
supply
current
operational
V
IQH = – 400 µA
VDD = 5 V
inputs at 0 V/VDD,
no outputs loads
0 V < VIN < VDD to 0 V
0 V < VOUT < VDD to 0 V
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.
User’s Manual
230
01.2000
PEB 20320
Electrical Characteristics
7.3
Capacitances
Table 14
TA = 25 °C; VDD = 5 V ± 5%, VSS = 0 V
Parameter
Symbol
Input capacitance
Output capacitance
I/O-capacitance
7.4
Limit Values
CIN
COUT
CIO
Unit
Test Condition
10
pF
–
15
pF
–
20
pF
–
min.
max.
5
8
10
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.
2.4
2.0
2.0
Device
Under
Test
Test Points
0.8
0.8
C Load = 150 pF
0.45
ITS00621
Figure 118
Input/Output Waveform for AC Tests
User’s Manual
231
01.2000
PEB 20320
Electrical Characteristics
7.5
Microprocessor Interface Intel Bus Mode
S1
S2
S1
SCLK
1
A31-A2
2
BE(3:0),
ADS
3
3
4
5
READY
6
7
BERR
8
D31-D0
(write cycle)
[DP(3:0)]
9
10
D31-D0
(read cycle)
[DP(3:0)]
PCHK
11
11
ITD03510
Figure 119
Timing Diagram Intel Bus Mode
User’s Manual
232
01.2000
PEB 20320
Electrical Characteristics
SCLK
12
12
HOLD
13
13
HLDAO
15
14
HLDA
16
Microprocessor
Interface
17
High Z
High Z
PCHK
11
ITD03511
Figure 120
Bus Arbitration Timing Diagram Intel Bus Mode
Intel Bus Timing
Table 15
No.
1
Parameter
Limit Values
Unit
min.
max.
Address, valid delay
–
20
ns
2
BE, INT, W/R valid delay
–
20
ns
3
ADS 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
User’s Manual
233
01.2000
PEB 20320
Electrical Characteristics
Table 15
No.
Parameter
Limit Values
Unit
min.
max.
11
Parity check valid delay
–
50
ns
12
HOLD valid delay
–
20
ns
13
HLDAO valid delay
–
20
ns
14
HLDA setup time
10
–
ns
15
HLDA hold time
10
–
ns
16
Microprocessor Interface (MI) driven
after HLDA set
2 SCLK cycles
–
–
17
MI tristated after bus accesses
–
40
ns
User’s Manual
234
01.2000
PEB 20320
Electrical Characteristics
7.6
Microprocessor Interface Motorola Bus Mode
T1
T3
T2
T4
T1
SCLK
18
A31-A2
INT, BE (3:0), R/W
20
26
AS
29
DS
19
28
19
21
21
DSACK
BERR
27
22
23
D31-D0
(read cycle)
25
24
D31-D0
(write cycle)
ITD03513
Figure 121
Timing Diagram Motorola Bus Mode
User’s Manual
235
01.2000
PEB 20320
Electrical Characteristics
SCLK
30
30
BR
31
32
BG
33
33
BGACK
Microprocessor
Interface
34
35
BGO
36
SCLK
BR
BG
36
36
BGO
ITD03514
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
User’s Manual
236
01.2000
PEB 20320
Electrical Characteristics
Table 16
No. Parameter
Limit Values
Unit
min.
max.
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.
User’s Manual
237
01.2000
PEB 20320
Electrical Characteristics
Serial Interface Timing
37
39
RSP
43
42
RCLK
38
40
41
RDATA
46
44
TSP
50
49
TCLK
45
48
47
TDATA
ITD03515
Figure 123
Table 17
No.
Parameter
Limit Values
Unit
min.
max.
10
–
ns
37
Receive strobe guard time
38
Receive strobe setup
5
–
ns
39
Receive strobe hold
5
–
ns
40
Receive data setup
5
–
ns
41
Receive data hold
5
–
ns
User’s Manual
238
01.2000
PEB 20320
Electrical Characteristics
Table 17 (cont’d)
No.
Parameter
Limit Values
Unit
min.
max.
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
Transmit data delay
–
40
ns
48
Transmit clock to high impedance
–
50
ns
49
Transmit clock high width
60
–
ns
50
Transmit clock low width
60
–
ns
Note: 1. The frequency on the serial line must be smaller or equal to
1 th
/8 of the frequency on the µP bus for 1.536 MHz, 1.544 MHz, 2.048 MHz
1/ th of the frequency on the µP bus for 4.096 MHz.
4
2. For complete internal or complete external loop t42 and t49 must be greater or
equal to 3 times t51.
Clock Input Timing
51
52
53
SCLK
ITD03516
Figure 124
Clock Timing
User’s Manual
239
01.2000
PEB 20320
Electrical Characteristics
Table 18
No.
Parameter
Limit Values
Unit
min.
max
51
Cycle period
50
–
ns
52
Clock low time
25
–
ns
53
Clock high time
25
–
ns
Note: If fT is the frequency of the clock TCLK, fR the frequency of the clock RCLK 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
AR
56
RESET
57
first action
request AR
after reset
55
ITT10668
Figure 125
Table 19
No.
Parameter
Limit Values
min.
Unit
max.
55
Reset to first action request delay 12 SCLK cycles
–
–
56
AR# pulse width
2 SCLK cycles
5 SCLK cycles
–
57
Reset pulse width
2 SCLK cycles
–
–
After power up a logical ‘1’ at the reset pin of the MUNICH V3.4 sets the device into a
reset state where the complete microprocessor bus interface is tristated and the internal
reset sequence is started.
User’s Manual
240
01.2000
PEB 20320
Electrical Characteristics
The trailing edge of the reset starts the last part of the internal reset 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
58
59
60
JTEST0 (TCK)
61
62
JTEST1 (TMS)
63
64
JTEST2 (TDI)
65
JTEST3 (TDO)
ITD03512
Figure 126
JTAG-Boundary Scan Timing
Table 20
Intel Bus Timing
No. Parameter
58
Limit Values
JTEST0 (TCK) period
Unit
min.
max.
166
inf
–
59
JTEST0 (TCK) high time
80
–
–
60
JTEST0 (TCK) low time
80
–
–
61
JTEST1 (TMS) setup time
15
–
–
62
JTEST1 (TMS) hold time
10
–
–
63
JTEST2 (TDI) setup time
15
–
–
64
JTEST2 (TDI) hold time
15
–
–
65
JTEST3 (TDO) valid delay
30
–
–
User’s Manual
241
01.2000
PEB 20320
Package Outlines
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
User’s Manual
242
01.2000
PEB 20320
Appendix
9
Appendix
9.1
Source Code Extract MUNICH32
The MUNICH32 code extract is taken from the low level device driver for the MUNICH32,
which is written in ‘C’. This extract gives you a brief impression how a MUNICH32 device
driver could be programmed.
The munich control configuration (munichCtrlCfg) is a structure which consists of the
following substructures:
Action Specification
Interrupt Queue Specification
Time-Slot Assignment
Channel Specification
Munich Receive Descriptor Pointer
Munich Transmit Descriptor Pointer
actionSpec
intQueueSpec
timeSlot[ ]
channelSpec[ ]
currRcDescrAddr[ ]
currTxDescrAddr[ ]
These substructures mainly consist of bit fields. The use of bit fields does not produce a
speed optimized but a highly readable code, in our case to demonstrate the
programming of the MUNICH32 very clearly.
The structures are directly memory mapped to the MUNICH32 structures and listed
below.
In this short 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.
User’s Manual
243
01.2000
PEB 20320
Appendix
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 activation 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.
User’s Manual
244
01.2000
PEB 20320
Appendix
9.2
Source Code
…
/*-------------------------------------------------------------------------- MUNICH32 Transmit Descriptor Structure
-------------------------------------------------------------------------*/
typedef struct
munichTxDescr
{
unsigned
fnum :
unsigned
csm :
unsigned
:
unsigned
v110 :
unsigned
no
:
unsigned
hi
:
unsigned
hold :
unsigned
fe
:
WORD8
_ptr data;
struct munichTxDescr
_ptr next;
}
MUNICH_TRANSMIT_DESCRIPTOR;
11;
1;
3;
1;
13;
1;
1;
1;
typedef MUNICH_TRANSMIT_DESCRIPTOR _ptr MUNICH_TX_DESCR_PTR
/*-------------------------------------------------------------------------- MUNICH32 Receive Descriptor Structure
-------------------------------------------------------------------------*/
typedef struct
munichRcDescr
{
unsigned
unsigned
no
unsigned
hi
unsigned
hold
unsigned
unsigned
unsigned
status
unsigned
bno
unsigned
unsigned
c
unsigned
fe
WORD8
_ptr data;
struct munichRcDescr
_ptr next;
}
MUNICH_RECEIVE_DESCRIPTOR;
User’s Manual
245
:
:
:
:
:
:
:
:
:
:
:
16;
13;
1;
1;
1;
8;
8;
13;
1;
1;
1;
01.2000
PEB 20320
Appendix
typedef MUNICH_RECEIVE_DESCRIPTOR _ptr MUNICH_RC_DESCR_PTR;
/*-------------------------------------------------------------------------- MUNICH32 Structures
-------------------------------------------------------------------------*/
typedef struct
{
unsigned channelNumber
unsigned rt
unsigned
unsigned fo
unsigned err
unsigned sf
unsigned ifc
unsigned fi
unsigned hi
unsigned arf
unsigned arack
unsigned x
unsigned sa
unsigned sb
unsigned e1
unsigned e2
unsigned e3
unsigned e4
unsigned e5
unsigned e6
unsigned e7
unsigned frc
unsigned
unsigned intFlag
}
MUNICH32_INTERRUPT_QUEUE;
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
typedef struct
{
MUNICH32_INTERRUPT_QUEUE _ptr
unsigned
unsigned
}
INTERRUPT_QUEUE_SPECIFICATION;
addr;
n : 8;
: 24;
5;
1;
2;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
4;
1;
typedef struct
{
unsigned
rcFillMask
: 8;
unsigned
rcChannelNumber : 5;
User’s Manual
246
01.2000
PEB 20320
Appendix
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
rti
:
:
txFillMask
:
txChannelNumber :
tti
:
:
1;
2;
8;
5;
1;
2;
}
TIME_SLOT_ASSIGNMENT;
typedef struct
{
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
MUNICH_RC_DESCR_PTR
MUNICH_TX_DESCR_PTR
unsigned
unsigned
}
CHANNEL_SPECIFICATION;
iftf
mode
fa
trv
crc
inv
tflagCs
tflag
ra
ro
th
ta
to
ti
ri
nitbs
intMask
frda;
ftda;
itbs
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1;
2;
1;
2;
1;
1;
1;
7;
1;
1;
1;
1;
1;
1;
1;
1;
8;
: 6;
: 26;
typedef struct
{
WORD32
}
CURRENT_RC_DESCR_ADDR;
*currentReceiveDescriptorAddrCh;
typedef struct
{
WORD32
}
CURRENT_TX_DESCR_ADDR;
*currentTransmitDescriptorAddrCh;
User’s Manual
247
01.2000
PEB 20320
Appendix
typedef struct
{
unsigned
unsigned
ia
unsigned
loopi
unsigned
loop
unsigned
loc
unsigned
res
unsigned
im
unsigned
channelNumber
unsigned
unsigned
ico
unsigned
in
unsigned
mfl
unsigned
pcm
}
ACTION_SPECIFICATION;
:
:
:
:
:
:
:
:
:
:
:
:
:
2;
1;
1;
1;
1;
1;
1;
5;
1;
1;
1;
13;
3;
/*-------------------------------------------------------------------------- MUNICH32 Control Block
-------------------------------------------------------------------------*/
typedef struct
{
ACTION_SPECIFICATION
INTERRUPT_QUEUE_SPECIFICATION
TIME_SLOT_ASSIGNMENT
CHANNEL_SPECIFICATION
MUNICH_RC_DESCR_PTR
MUNICH_TX_DESCR_PTR
}
MUNICH32_CTRL_CFG_SECTION;
..
..
User’s Manual
actionSpec;
intQueueSpec;
timeSlot
channelSpec
currRcDescrAddr
currTxDescrAddr
248
32;
32;
32;
32;
01.2000
PEB 20320
Appendix
/*-------------------------------------------------------------------------- Function
: InitChannel0AndSendFirstFrame
-------------------------------------------------------------------------- Description : Initialization of channel 0.
- PCM Highway format CEPT 32-channel
- HDLC Mode
- All timeslots are assigned to channel 0.
- Send the first HDLC 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 =====================================*/
munichCtrlCfg.intQueueSpec.addr
munichCtrlCfg.intQueueSpec.n
/* interrupt queue address */
= &munichIntQueue [0];
/* interrupt queue size */
= (INT_QUEUE_SIZE_MAX / 16 -1);
for ( i = 0; i < INT_QUEUE_SIZE_MAX; i++ )
{
munichIntQueue[i].intFlag = CLEAR;
}
User’s Manual
249
/* Reset interrupt queue */
01.2000
PEB 20320
Appendix
/*=== Timeslot Assignment ===============================================*/
for ( i = 0; i < 32; i++)
{
munichCtrlCfg.timeSlot[i].rcChannelNumber
munichCtrlCfg.timeSlot[i].txChannelNumber
munichCtrlCfg.timeSlot[i].rcFillMask
munichCtrlCfg.timeSlot[i].txFillMask
munichCtrlCfg.timeSlot[i].tti
munichCtrlCfg.timeSlot[i].rti
}
=
=
=
=
=
=
/*
0;
/*
0;
/*
0xFF;/*
0xFF;/*
0;
/*
0;
/*
For all timeslots
assigned to
channel 0
all bits assigned
per channel
Tx output active
Rc input active
*/
*/
*/
*/
*/
*/
*/
/*=== Channel Specification =============================================*/
munichCtrlCfg.channelSpec[channel0].intMask
munichCtrlCfg.channelSpec[channel0].nitbs
munichCtrlCfg.channelSpec[channel0].to
munichCtrlCfg.channelSpec[channel0].ta
munichCtrlCfg.channelSpec[channel0].ti
munichCtrlCfg.channelSpec[channel0].ro
munichCtrlCfg.channelSpec[channel0].ra
munichCtrlCfg.channelSpec[channel0].ri
=
=
=
=
=
=
=
=
0; /* interrupts enabled
1; /* new ITBS value
0; /* transmit
1; /* initialization
1; /*
0; /* receive
1; /* initialization
1; /*
*/
*/
*/
*/
*/
*/
*/
*/
munichCtrlCfg.channelSpec[channel0].th
munichCtrlCfg.channelSpec[channel0].fa
munichCtrlCfg.channelSpec[channel0].tflag
munichCtrlCfg.channelSpec[channel0].tflagCs
munichCtrlCfg.channelSpec[channel0].inv
munichCtrlCfg.channelSpec[channel0].crc
munichCtrlCfg.channelSpec[channel0].trv
munichCtrlCfg.channelSpec[channel0].mode
munichCtrlCfg.channelSpec[channel0].iftf
munichCtrlCfg.channelSpec[channel0].itbs
=
=
=
=
=
=
=
=
=
=
0;
0;
0;
0;
0;
0;
0;
3;
0;
9;
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
munichCtrlCfg.channelSpec[channel0].ftda
User’s Manual
250
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
no transmit hold
no flag adjustment
only for TMA
CRC select
no bit inversion
16-bit CRC
transmission rate
HDLC Mode
idle code flags
transmit buffer size
= txDescr; /* first transmit
*/
/* descriptor address */
01.2000
PEB 20320
Appendix
/*=== Transmit Descriptor ===============================================*/
/* the next pointer of the last txDescr points to the zero pointer
*/
for ( ; txDescr ->next; txDescr
{
txDescr ->fnum
= 3;
txDescr ->hold
= 0;
txDescr ->hi
= 0;
txDescr ->fe
= 0;
txDescr ->v110
= 0;
}
txDescr ->fe
= 1;
txDescr ->hold
= 1;
*/
*/
= txDescr ->next )
/*
/*
/*
/*
/*
3 interframe timefill char
*/
clear hold bit
*/
clear host initiated interrupt bit */
clear frame end bit
*/
clear v110 bit
*/
/* set frame end bit
/* set hold bit
/*=== Receive Descriptor ================================================*/
rcDescr
= AllocReceiveDescriptor(10);
munichCtrlCfg.channelSpec[channel0].frda
/* Alloc e.g. ten
/* receive descriptors
/* with 32 data byte each
*/
*/
*/
= 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 */
}
/*=== Prepare The Last Receive Descriptor, Number 10 ====================*/
rcDescr
rcDescr
rcDescr
rcDescr
rcDescr
->hold
->hi
->no
->fe
->c
=
=
=
=
=
1;
1;
32;
0;
0;
channelControl[0].lasttxdescr
channelControl[0].lastrcdescr
MUNICH32_ACTION_REQUEST ();
/*
/*
/*
/*
/*
last available descriptor
no host interrupt
32 data byte available
clear frame end bit
clear data section complete bit
*/
*/
*/
*/
*/
= txDescr; /* store last transmit pointer */
= rcDescr; /* store last receive pointer */
/* generate MUNICH32 activation request */
}
User’s Manual
251
01.2000
PEB 20320
Appendix
/*-------------------------------------------------------------------------- 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 ->fnum
= 3;
txDescr ->hold
= 0;
txDescr ->hi
= 0;
txDescr ->fe
= 0;
txDescr ->v110
= 0;
}
txDescr ->fe
= 1;
txDescr ->hold
= 1;
= txDescr ->next )
/*
/*
/*
/*
/*
3 interframe timefill char
*/
clear hold bit
*/
clear host initiated interrupt bit */
clear frame end bit
*/
clear v110 bit
*/
/* set frame end bit
/* set hold bit
channelControl[0].lasttxdescr ->hold = 0;
channelControl[0].lasttxdescr
/*
/*
/*
/*
/*
*/
*/
the polling MUNICH32
will then detect the
cleared hold bit and
send the following
frame
*/
*/
*/
*/
*/
= txDescr; /* store last transmit pointer */
}
User’s Manual
252
01.2000