IEEE Std 1149.5-1995 IEEE Standard for Module Test and Maintenance Bus (MTM-Bus) Protocol Sponsor Test Technology Standards Committee of the IEEE Computer Society Approved August 14,1995 IEEE Standards Boar Abstract: This Standard specifies a serial, backplane, test and maintenance bus (MTM-Bus) that can be used to integrate modules from different design teams or vendors into testable and main- tainable subsystems. Physical, link, and command layers are specified. Standard interface protocol and commands can be used to provide the basic test and maintenance features needed for a mod- ule as well as access to on-module assets (memory, peripherals, etc.) and IEEE Std 1149.1 bound- ary-scan. Standard commands and functions support fault isolation to individual modules and test of backplane interconnect between modules. Keywords: backplane bus, boundary scan, built-in self-test, maintenance, MTM-Bus, subsystems, system diagnostics, system test, testing The Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street, New York, NY 1001 7-2394, USA Copyright 0 1996 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 1996. Printed in the United States of America. ISBN 1-55937-558-2 No part of this publication may be reproducedin any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.
Transcript
IEEE Std 1149.5-1995
IEEE Standard for Module Test and Maintenance Bus (MTM-Bus) Protocol
Sponsor
Test Technology Standards Committee of the IEEE Computer Society
Approved August 14,1995
IEEE Standards Boar
Abstract: This Standard specifies a serial, backplane, test and maintenance bus (MTM-Bus) that can be used to integrate modules from different design teams or vendors into testable and main- tainable subsystems. Physical, link, and command layers are specified. Standard interface protocol and commands can be used to provide the basic test and maintenance features needed for a mod- ule as well as access to on-module assets (memory, peripherals, etc.) and IEEE Std 1149.1 bound- ary-scan. Standard commands and functions support fault isolation to individual modules and test of backplane interconnect between modules. Keywords: backplane bus, boundary scan, built-in self-test, maintenance, MTM-Bus, subsystems, system diagnostics, system test, testing
The Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street, New York, NY 1001 7-2394, USA
Copyright 0 1996 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 1996. Printed in the United States of America.
ISBN 1-55937-558-2
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.
IEEE Standards documents are developed within the Technical Committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in partici- pating in the development of the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, mar- ket, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.
Comments for revision of regardless of membership affiliatio ments should be in the form of a supporting comments.
Interpretations: Occasionally meaning of portions of standards as they relate to
any interested party, ons for changes in docu- together with appropriate
ests, it is important to ensure that an
mittees are not able to those cases where the matter has previously received
Comments on standards and requ
has also received the concurrence the members of its technical com-
n requests except in
uld be addressed to:
Sec 445 P.O. Box 1331 Piscataway, NJ 08855-1331 USA
I I IEEE Standards documents may involve the use of patented technology. Their approval by the Institute of Electrical and Electronics Engineers does not mean that using such technology for the purpose of conforming to such standards is authorized by the patent owner. It is the obligation of the user of such technology to obtain all necessary permissions.
Introduction
[This introduction is not part of IEEE Std 1149.5-1995, IEEE Standard for Module Test and Maintenance Bus (MTM-Bus) Protocol.]
The purpose for developing this Standard is to provide a cost-effective and standardized backplane module test and maintenance interface that can be used to integrate testable modules from different design teams or vendors into testable and maintainable subsystems. Standard interface protocol and commands can be used to provide the basic test and maintenance features needed for a module as well as access to on-module assets (memory, peripherals, etc.) and IEEE Std 1149.1 boundary-scan. Standard commands and functions support fault isolation to individual modules and test of backplane interconnect between modules.
The origins of the protocol for this Standard date back to the United States Department of Defense Very High Speed Integrated Circuits (VHSIC) program in 1986. In that program there was a need to develop a test and maintenance architecture that would be common between the three contractors (Honeywell, IBM, and TRW). This test and maintenance architecture included a backplane test and maintenance bus as well as a chip-level test bus. The backplane test and maintenance bus was further developed for use in several advanced avionics programs. Following the completion of these applications to avionics, significant interest in developing an industrial standard based on this test and maintenance bus were registered. The level of interest was sufficient to initiate the development of a backplane test and maintenance protocol standard as a sibling to the other test-related buses that were being developed in the IEEE 1149 group of standards (1990). The chip-level test architecture of the VHSIC program had previously been folded into IEEE Std 1149.1.
Work on the module test and maintenance bus (referred to herein as “MTM-Bus”) began with the final draft from the previous Department of Defense efforts. This draft was significantly modified to remove all project specific artifacts from previous standardization efforts ant1 generalized 10 allow applicability to all types of systems. An additional major effort was required to clarify anibiguiiics so Lhat different vendors of IEEE Std 1149.5 protocol chips could provide parts able to communicate and be interoperable. The total revision and expansion effort took approximately four years and added almost 150 pages to the document. It is interesting to note that the document went through a letter ballot review by more than 100 engineers, who had no sub- stantial comments, except for one negative review (later withdrawn) that disagreed with the fundamental nature of the interface.
In 1995, the VME Standards Organization (VSO) included the IEEE Std 1149.5 MTM-Bus in their VME64 group of standards, which specifies a backplane for embedded systems. Work is continuing on the applica- tion of the MTM-Bus in VME64 standard extensions and applications.
At the time of approval of this standard, the PI 149.5 MTM-Bus Working Group had the following member- ship:
Patrick F. McHugh, Chair Rodham E. ’lhlloss, Technical Editor
Dave Heiligenstein Christopher M. Henwood Chuck Hudson
Gerry Kendzior Russell A. Mansfield
Jeffrey W. Lundy Michel Parot Gregory D. Young
... 1 1
The following persons were on the balloting committee:
Jacob A. Abraham Dharma €? Agrawal John Andrews Sanjay Bajaj Behrooz Bandall Elizabeth Benedict Dilip K. Bhavsar Harry Bleeker Federico Bonzanigo David W. Browne Harold W. Carter R. Chandramouli John P. Chihorek Wilton Chiles John Crownover R. Dandapani Wayne Daniel Steven Dollens Samuel Duncan Leo G. Egan William Eklow John H. Erickson Carles Ferrer Peter Fleming Andrew Fraser Walter Geisselhardt Dong S. Ha Harry E. Hansen C. H. Hao Richard Harms Werner Hauptmann Leonard Hause Charles Hawkins Alan Heam Wei-Cheng Her Charles Holliday
Kenneth Hoyme Chuck Hudson Masaaki Inadachi Neal Jaarsma Najmi Jarwala M. A. Anura P. Jayasumana Wen-Ben Jone Carl Kagy Bozena Kaminska Jake Karrfdt Mehdi Katoozi William Keiner Charles Kime Steven K. Ladd David Landis Bjom B. Larsen Luis Larzabal Robert Ledbetter Ben Lee Marc Levitt Jeffrey W. Lundy R. A. Mansficld Ken Mason Colin Maunder Thomas J. McGrath Earl Meiers Alcx Mcloni Yinghua Min Malh Muris H. Troy Nagle, Jr. Prmvnt Nnpvajim Jillrlcs NilLIy IZO? I I . Ncx!;l)ll
I’ill I ! ( )GI I I lp i )
Yoaliiiiori h’ino1iir;i :\: i1i)lil Nortlsicck
Michel Parot
Robin Passow Stephen Pizzica Paolo Prinetto Rochit Rajsuman Edward Ramirez Edward P. Ratazzi Shishpal Rawat William T. Rhoades Gordon Robinson Robert Rolfe Kenneth Rose Fred U. Rosenberger Cayetano Sanchez Sudha Sarma William H. Smith Mani Soma Gerard N. Stenbakken James H. Stewart Jacques Tete Cihan Tinaztepe Erwin Trischler Joseph G. Tront Rodham E. Tulloss Jon L. Turin0 Louis Y. Ungar Dirk Van de Lagemaat Russell J. Wagner J. Richard Weger Harry Whittemore Werner Wolz Cheng-Wen Wu Chi Yau Homayoun Yazdanpanah Greg D. Young Farzad Zarrinfar Guenther Zwiehoff
iv
When the IEEE Standards Board approved this standard on August 14, 1995, it had the following membership:
E. G. “AI” Kiener, Chair Donald C. Loughry, Vice Chair Andrew G. Salem, Secretary
Gilles A. Baril Clyde R. Camp Joseph A. Cannatelli Stephen L. Diamond Harold E. Epstein Donald C. Fleckenstein Jay Forster” Donald N. Heirman
Richard J. Holleman Jim Isaak Ben C. Johnson Sonny Kasturi Lorraine C. Kevra Ivor N. Knight Joseph L. Koepfinger* D. N. “Jim” Logothetis L. Bruce McClung
*Member Emeritus
Also included are the following nonvoting IEEE Standards Board liaisons:
Satish K. Aggarwal Richard B. Engclman Robert E. Hebner Chester C. Taylor
Marco W. Migliaro Mary Lou Padgett John W. Pope Arthur K. Reilly Gary S. Robinson Ingo Rusch Chee Kiow Tan Leonard L. Tripp
Scope and objectives .............................................................................................................. 1-1 Interconnection of modules with MTM-Bus .......................................................................... 1-2 Relationship to other test buses .............................................................................................. 1-3 Overview of MTM-Bus operatiodprotocol ........................................................................... 1-3 MTM-Bus protocol layers ...................................................................................................... 1-5 Extensions to this Standard .................................................................................................... 1-6
2 . Conventions. definitions. and references .......................................................................................... 2. 1
NULL packet requirements .................................................................................................... 5-5 Formatting bit strings of more than 16 bits for transmission in DATA packets .................... 5-5
6 . MTM-Bus Link Layer: M-module requirements .............................................................................. 6-1
6.1 6.2 6.3 6.4 6-5
MTM-Bus Master Link Layer Controller (M-Controller) requirements ................................ 6-1 M-module send and receive parity requirements ................................................................... 6-9
M-module response to collision errors on MMD and MCTL signals .................................. 6-11 M-module interrupt response requirements .......................................................................... 6-11
M-module MPR signal (data transfer control) requirements ............................................... 6-10
vii
CLAUSE PAGE
7 . MTM-Bus Link Layer: S-module requirements-h4TM-Bus Save Link Layer Controller ............ 7-1
14.1 S-module general HEADER packet decode and general command response requirements ......................................................................................................................... 14-1
MTM-Bus Message Layer: Data Transfer class commands (0100000-0100111) ......................... 17-1
17.1 General format requirements for Data Transfer class commands ........................................ 17-1 17.2 Read Data command (0100000) ........................................................................................... 17-2 17.3 Write Data command (0100001) .......................................................................................... 17-4 17.4 ReaWri te Data command (0100010) ................................................................................. 17-5 17.5 Reserved commands (0100011-0100111) ........................................................................... 17-7
MTM-Bus Message Layer: Module Initialization and Self-Test (MIST) class commands (OlOOOoo-OlOOl1) .......................................................................................................................... 18-1
General requirements for MIST commands ......................................................................... 18-2
Reset Module Without SBIT command (0101001) .............................................................. 18-4
ix
CLAUSE PAGE
19.
20.
21.
22.
MTM-Bus Message Layer: Module I/O Control and Test (MICT) class commands (0110000-0110111) ....................................................................................................................... 19-1
19.1 MICT class commands-general requirements ................................................................... 19-2
19.7 Sample Module Don’t Care command (0110100) ..................................... 19-11
MTM-Bus Message Layer: Standard Extension class commands (101000&101 11 11) and User-Defined class commands (1 10000&1111110) ..................................................................... .20- 1
20.1 Standard Extension class commands
21.2 Port definition and doc 2 1.3 ModuleiFault log port(
IEEE Standard for Module Test and Maintenance Bus (MTM-Bus) Protocol
1. Overview
1.1 Scope and objectives
1.1.1 Scope
This document standardizes a serial, backplane, test and maintenance bus (referred to herein as “MTM-Bus”), consisting of one or more logic boards, that can be used to integrate modules from different design teams or vendors into testable and maintainable subsystems. (In this document “board” is used in a broad sense to mean an assembled, usually field-replaceable, unit immediately above the device-level in a system’s assembly hierarchy-e.g., assembled printed wiring boards, assembled multichip modules, etc.) The bus protocol defined in this document standardizes a method for communication of test and mainte- nance commands and serial data between a subsystem test control module (MTM-Bus Master module) and the other modules (MTM-Bus Slave modules) on the bus. The MTM-Bus may be implemented as part of an overall test and maintenance interface architecture that includes other test buses.
1.1.2 Objectives
The MTM-Bus is intended for use in the testing, diagnosis, and maintenance of electronics subsystems and modules. Permissions and recommendations have been incorporated into the MTM-Bus protocol that allow it to be tailored for use in commercial computers, telecommunications, avionics, defense electronics, and many other applications. The MTM-Bus may be used to support the following:
- Module test. Testing of modules during manufacturing to provide fault isolation of defects to individ- ual components.
- Subsystem test. Off-line testing of modules while contained within a subsystem, and the testing of interconnections between modules within a subsystem.
- Subsystem diagnostics. On-line diagnostics within a system to support logging of detected errors, ini- tiation of self-test, reconfiguration of subsystem resources, and other diagnostic functions.
- Sojiwarehardware development, Access to a module or subsystem state by use of low-level observ- ability/controllability techniques (e.g., scan, boundary scan, etc.). Use of these techniques may allow for reduced hardwarehoftware development costs and decreased time to market.
To support these applications, the MTM-Bus is designed as a serial backplane bus with a multidrop topol- ogy. As the multidrop bus signals are common between all modules, a board may be removed from the back- plane without breaking the communication link between other modules in the backplane. With the appropriate Physical Layer design, the protocol supports access between a single MTM-Bus Master module and up to 250 individually addressable MTM-Bus Slave modules. Addressing is defined so that the MTM- Bus Master may communicate with one, some, or all of the Slaves at one time. The physical backplane char- acteristics will define the maximum number of MTM-Bus modules that can be used in a given application.
A primary concern in the development of the MTM-Bus Standard was to minimize the cost of implementa- tion while still deriving the benefits of improved testability and maintainability. For this reason, a serial bus with a limited number of signals was selected. A masterklave protocol is used to keep the protocol simple; thereby reducing interface circuitry and software requirements. The bus is synchronous to simplify the back- plane design and to simplify simulation of bus performance.
1-1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Because the MTM-Bus may be used to transmit a significant amount of data, such as serial test patterns, the protocol supports full duplex data transfer operations. Although the detailed timing and electrical parameters of the bus are not specified in this document, a general timing approach is defined that allows a MTM-Bus interface device to support a broad range of applications. The maximum bus performance for a particular system is governed by the maximum capabilities of the bus interface devices and the worst-case system tim- ing budget. To aid interoperation of modules from multiple vendors, a dual-edge clocking approach is uti- lized. The dual-edge approach allows the system designer to select a MTM-Bus clock waveform that balances the system performance requirements with the modules’ capabilities and the backplane timing parameters.
As the bus is intended to be usable in-system, the bus provides a number of fault detection and fault toler- ance features. Optional features have been defined that may be included for a particular test architecture.
To support the requirements described previously, the protocol identifies commands to provide for the fol- lowing functions:
- Initialization of modulelsubsystem - Accessing lower-level test buses - Testing of module interconnections - Interrupt control and handling - Accessing module identification - Accessing module fault logs - Forcing modules off- and on-line - Accessing module built-in - Private and public user extens
1.2 The interconnection of
As designs have become more complex and difficult to test, design-for-test features (e.g., internal scan, IEEE Std 1149.1 boundary-scan, and built-in test) are being integrated into component designs to aid in component, board, subsystem, and system test and maintenance. Since these techniques do not use “func- tional” methods to test the circuitry, alternate paths are needed to access on-chip design-for-test features. These alternate paths have to be kept both simple and dedicated to test and diagnostic functions so that boot- strapping to complete module testing from a testable kernel is feasible.
When components are assembled on boards, boards into subsystems, and subsystems into systems, a hierar- chy of test buses is needed to retain access to the design-for-test features in the final product. Such a hierar- chy of test buses is depicted in figure 1-1. The MTM-Bus has been developed to meet the requirements for a backplane bus in such a bus hierarchy. As shown in figure 1-1, the =-Bus provides subsystem test con- trol (e.g., maintenance module, service console, etc.) access or external test equipment access to test features on modules within a subsystem.
The actual use of the MTM-Bus will vary with the system test and maintenance strategy adopted. Two extremes would be highly “centralized” and highly “distributed” approaches. A distributed approach pushes as much of the test and maintenance function to the individual modules as possible. A centralized approach uses a centralized test control module or serial test equipment to sequence low-level module testing steps. The benefits of both distributed and centralized approaches are outlined in the following lists.
Benefits of distributed approach:
-
-
1-2
Interoperability. In a system where modules are provided by a number of different design teams, a distributed approach allows backplane integration to proceed more smoothly. Reduction in test time. It is possible that test time at the system level can be reduced if two or more modules can be tested concurrently.
MAINTENANCE BUS (MTM-BUS) PROTOCOL
Component Level Test Bus Other Other MTM-Bus
Components
t , c Comp. 2
Interface Logic 2 Application 0)
%
U K 3 0
Subsystem Test- bus Test - Testcontrol U Interface U
m Component ~
Board or Module Rack or Subsystem
IEEE Std 1149.5-1995
System Bus
NOTE-Hierarchical serial test buses may be used to access module- and component-level design-for-test features.
Figure 1-1 -Hierarchy of test and maintenance buses
- SimpliJcation of software. Since the distributed test circuitry and software allows for higher-level test functionskommands, less software is required in the Subsystem Test Control module (figure 1-1) for each specific type of module. Distributed software can reduce the software development time and simplify module upgrades. Containment of bus trafic. If self-test routines and test patterns are contained on the individual mod- ules, bus traffic is restricted to high-level commands and compressed test results.
- Znterchangeability. If test patterns or procedures specific to a module’s low-level design are con- tained within the module, then modules with identical function, but different design, can be made fully interchangeable.
-
Benefits of a centralized approach:
- Cost reduction. By centralizing the te on to a single processor on a Subsystem Test Control module (figure 1-l), test seq y is not required on each module. This can reduce the cost of the test interface and control circuitry on each module within the system. Simplicity. If the test interface on each module does not contain any module-specific test information, a common test interface can be used on a large number of modules without need for module-specific programming.
-
1.3 Relationship to other test buses
The MTM-Bus is intended for use as a backplane serial test bus that may be used in parallel with, or in an hierarchy with, other test buses. The MTM-Bus and on-module test buses may be connected as shown in fig- ure 1-2 to allow access to the component test features.
1.4 Overview of MTM-Bus operation/protocol
The MTM-Bus is a synchronous, serial, backplane bus comprised of four required signals and an optional fifth signal, as detailed in figure 1-3. An MTM-Bus Master module can communicate with up to 250 individ- ually addressable MTM-Bus Slave modules. The bus is designed to have a single bus master; however, bus mastership may be transferred to backup masters in fault-tolerant configurations of the bus. The multidrop architecture and addressing capabilities of this Standard allow the MTM-Bus Master to address and commu- nicate with one, some (multicast), or all (broadcast) of the MTM-Bus Slave modules on the bus.
1-3
IEEE Std 1149.5-1995 lEEE STANDARD FOR MODULE TEST AND
T I I
Other Board.
I r
-level Test 1149.1 Test : Bus
NOTE-Translation may be provided by the use of a test-bus interface device. A separate bus transceiver may also be used to customize the physical protocol for specific applications.
Figure 1 -2-Translation between the MTM-Bus and on-module test buses
Clock Source
L ._ .
NOTE-These signals include the test-bus clock (MCLK [free-running and externally sourced in this example]), MTM-Bus Master and Slave Data signals (MMD and MSD), the Control signal (MCTL), and the rec- ommended Pause Request signal (MPR).
Figure 1-3- Backplane MTM-Bus signals
The MTM-Bus Master communicates with MTM-Bus Slaves using messages that consist of a series of packet transfers. A message consists of a HEADER packet, an optional ACKNOWLEDGE/PACKET COUNT packet, and a variable number of DATA packets.
Figure 1-4 depicts a standard format for an MTM-Bus message. To start a message, the MTM-Bus Master transmits a HEADER packet that includes the addresses of the MTM-Bus Slaves who are to participate in the message sequence along with a command. If a single MTM-Bus Slave is addressed and the HEADER packet includes a request for an ACKNOWLEDGE packet, the MTM-Bus Master sends the PACKET
1-4
IEEE MAINTENANCE BUS (MTM-BUS) PROTOCOL Std 1149.5-1995
COUNT packet while the addressed MTM-Bus Slave is returning the ACKNOWLEDGE packet. This PACKET COUNT packet identifies how many packets the MTM-Bus Master expects to transfer during the message exclusive of HEADER and PACKET COUNT packets. The message may then include the transfer of DATA packets between the MTM-Bus Master and the single addressed MTM-Bus Slave module depend- ing upon the command. If multiple MTM-Bus Slaves are addressed (i.e., via broadcast or multicast address- ing), no ACKNOWLEDGE packet is sent and any transfer of DATA packets is only from the MTM-Bus Master to the MTM-Bus Slaves. In the broadcast and multicast cases, the MTM-Bus Master receive a con- stant logic &the value of the Slave Data line (figure 1-3) when it is not actively driven by any MTM-Bus Slave. The number of DATA packets to be transferred is dependent upon the type of command contained within the HEADER packet.
MASTER MODULE PACKETS SLAVE MODULE PACKETS
I I
I PACKETCOUNT I 7 I ACKNOWLEDGE I st M-module DATA I I 1st S-module DATA I
NOTE-MTM-Bus messages consist of a single HEADER packet, an optional ACKNOWLEDGUPACKET COUNT packet pair, and a variable number of DATA packet pairs.
Figure 1-&Sample MTM-B message format
All packet transfers occur under the control of the MTM-Bus Master module. Addressed MTM-Bus Slave modules may request that the MTM-Bus Master insert additional Pause states between data packet transfers by asserting the Pause Request (MPR) signal. This feature may be used to accommodate slow MTM-Bus Slaves or to simplify data flow control across asynchronous interfaces.
MTM-Bus Slave modules may also request the attention of the MTM-Bus Master by sending an interrupt, multiplexed on the Slave Data (MSD) signal wire, at any time between packet transfers. As there is only one MSD input to the MTM-Bus Master module, the MTM-Bus Master may need to identify the interrupting module via polling or by the Contend for Bus command (16.4.1).
1.5 MTM-Bus protocol layers
The individual layers of the MTM-Bus protocol are identified in this document to simplify understanding of the bus protocol and to clarify bus requirements. The bus protocol includes Physical, Link, and Message Layers as shown in figure 1-5.
1-5
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
The Physical Layer requirements specify the physical interconnections that comprise the bus. This includes the specification of the minimum requirements regarding physical interconnections, signal characteristics, and timing characteristics. The minimum requirements for the Physical Layer are specified in clause 4. The Physical Layer characteristics that are specific to system technology are not defined in this Standard.
The architecture of the MTM-Bus and its addressing scheme are specified in clause 3.
The Link Layer requirements specify the protocol features that permit error-free packet transfer between the MTM-Bus Master and one or more MTM-Bus Slaves. These features include serialization/packetization of information, parity generation and checking, and address recognition. The Link Layer also provides for the multiplexing of data and control functions on single wires. The requirements for the Link Layer are specified in clauses 5 through 11 of this Standard.
Message Layer
Applications
Master Link
Layer
Message Applications Layer
Physical Layer I NOTE-The MTM-Bus protocol includes Physical Layer, Link Layer, and Message Layer protocols.
Figure l-5-Protocol layers
Message layer requirements specify thc SYllIilY f o r inessages and id fies the functions that have to or can be supported by the MTM-Bus Mastcr o r klTM Bus Slaves. Requirements for the Message Layer are speci- fied in clauses 12 through 20.
Port requirements describe a set of recommended or permitted data sourcesldestinations (called ports) that may be useful in some S-modules. A port may be as simple as a register or as complex as an application interfacing this Standard to an on-module test bus. Data is transferred to/from ports during execution of Data Transfer class (15.1.1; clause 17) commands. Requirements for ports are found in clause 21. Requirements for recommended ports interfacing an MTM-Bus to the IEEE Std 1149.1 test bus are found in clauses 21.10 through 21.12.
Documentation requirements are to be found in clause 22.
1.6 Extensions to this Standard
The basic protocol defined herein for the MTM-Bus may be extended to meet the needs of specific applica- tions-as detailed by the recommendations and permissions. These extensions may address such areas as fault tolerance, electrical characteristics, and others that allow the I~fr'M-Bus to be adapted to user applica- tions.
An example of one of these MTM-Bus-based extensions is a test and maintenance bus system for avionics applications that is being developed by the Society of Automotive Engineers (SAE) Avionics Systems Divi- sion members (see SAE AS4765).' This system will contain dual MTM-Buses (2 sets of 5-wire MTM-
'Information on references can be found in 2.4.
1-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
Buses), a fault recovery protocol, and additional Physical Layer requirements. This system will also include a protocol allowing “backup” MTM-Bus Master modules to monitor bus traffic to verify that the current MTM-Bus Master module is functioning correctly.
1-7
IEEE Std 1149.5-1995
2. Conventions, definitions, and references
2.1 Document outline
Bus protocols such as that defined by this Standard are more easily understood if their specifications are accompanied by general descriptive material that places the details of the various parts of the protocol in perspective and provides implementation examples. Clause 1 contains an overview of the application of this Standard to test and maintenance of electronics subsystems. Clause 2 contains reference information that should be helpful in interpreting the subsequent clauses of the Standard. Clauses 3 through 22 contain the specifications for particular features of this Standard. The two classes of material contained in clauses 3 through 22 are described in 2.1 1 and 2.1.2.
2.1.1 Specifications
Subclauses entitled “Specifications” contain the rules, recommendations, and permissions that define this Standard:
- Rules specify the mandatory aspects of this Standard. Specifications that are rules contain the word shall.
Recommendations indicate preferred practice for designs that seek to conform to this Standard. Specifica- tions that are recommendations contain the word should.
Permissions show how optional features may be introduced into a design that seeks to conform to this Stan- dard. These features will extend the application of the protocol defined by the Standard. Specifications that are permissions contain the word may.
2.1.2 Descriptions
Material not contained in subclauses entitled “Specifications” is descriptive material that illustrates the need for the features being specified, an example of their application, or other relevant information. This material includes bus packet or message sequences or schematic t illustrate a possible implementation of the specifications in this Standard. The descriptive material discusses design decisions made during the development of this Standard.
NOTE-The descriptive material contained in this Standard is for illustrative purposes only and does not define a preferred implementation.
2.2 Conventions
The following conventions are used in this Standard:
a) The rules, recommendations, and permissions in each Specifications subclause are contained in a single alphabetically indexed list. References to each rule, recommendation, or permission are writ- ten in the following form:
15.1. IC (ii)
‘1 Subclause number
Index (if any)
b) State and packet names defined in this Standard are written entirely in capital letters in the text of this Standard.
2- 1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
c)
d)
e)
f)
g)
A positive logic convention is used for all figures io this document, i.e., a logic 1 value designates the most positive of the two voltages used for signals, including the MTM-Bus clock signal, MCLK. When a set of related bits are denoted by a common name, the bits within the set are identified by number with the least significant bit numbered 0. The identifier for a single bit in a series of related bits (e.g., a packet) is the bit position number in the series enclosed in angle brackets (“e” and ‘5”). The expression <m..n> is used as an abbreviated identifier for a series of bits m to n, inclusive (e.g., the bits in a register or packet), where m and n are the most and least significant bits, respectively. The phrases “signal driver(s),” “signal output(s),” and “signal input@),” when implicitly or explic- itly refemng to MTM-Bus signals, shall be taken to refer to one or more MTM-Bus signals exclu- sive of MCLK unless explicitly indicated otherwise. M-module is used as an abbreviation for “MTM-Bus Master module.” S-module is used as an abbreviation for “MTM-Bus Slave module.” In all diagrams depicting registers, packets, and data fields within registers and packets, the most significant bit (msb) of each depicted element is assumed to be left-most within the rectangle defin- ing the data entity. Any reference to a figure in this document is intended to reference all drawings and text in that fig- ure.
h) i) j)
k)
2.3 Definitions
The following terms are used within this Stantiard. Clause, subclause, table, or figure numbers are given in parentheses to indicate specific places in the text where terms are discussed in detail.
2.3.1 ACKNOWLEDGE packet: The first packet returned by an individually addressed S-module that con- veys to the M-module that the appropriate S-module is responding and indicates the current status of the responding S-module (5.3).
2.3.2 active: When associated with a logic level (e.g., in the word “activc-low”), this term identifies the logic level to which a signal shall be set to cause a defined action io occur. When referring to an output driver (e.g., in the phrase “an active driver”), this term describes the mode in which the driver is capable of determining the voltage of the network to which it is connected
2.3.3 amnesia address: The module address (‘FA’ HEX) to which a module will respond as though uniquely addressed if that module (1) i~ii~~loiiimls thc abilily lo 11~l;f~~t w l i o i iI ciilmot determine its address unambiguously and (2) detects that it c‘Iiiiio1 t k k i iiiiiic. its atltlrcsh on;itr~higtioiisl~ (3.3).
2.3.4 application logic: That portion of a module that excludes the MTM-Bus interface logic (figure 2-1).
2.3.5 assert: To change the value of a bus signal from logic 0 (released) to logic 1 (asserted) or ensure that such a signal remains at a logic 1.
2.3.6 asserted: Having a current value equal to logic 1 (said of any signal).
2.3.7 backplane: Motherboard comprising connectors for the modules of a system and wiring interconnect- ing those modules. The intermodule wiring of the MTM-Bus is expected to be on this motherboard.
2.3.8 BMR: Acronym for “broadcastlmulticast received.” See 2.3.10.
2.3.9 broadcast: A mode of operation of the MTM-Bus in which an MTM-Bus Master transmits data to all connected S-modules simultaneously throughout a message. Also, a message transmitted in this mode.
2-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
2.3.10 Broadcast/Multicast Received (BMR) bit: A bit in the Bus Error register of all S-modules. An S-module sets this bit to indicate that the last broadcast or multicast message was received without error (9.3).
2.3.11 BSE: Acronym for “Bus Error.” (See 2.3.14.)
2.3.12 BSY: Acronym for “Slave Busy.” (See 2.3.123.)
2.3.13 BTL: Acronym for “backplane transceiver logic.”
2.3.14 Bus Error (BSE) bit: A bit in the Slave Status register of every S-module that is set by the S-module when a Bus Error is recorded in the Bus Error register (9.2).
2.3.15 Bus Error register: A status register that is required to be implemented in the MTM-Bus interface circuitry of every S-module. Bits in this register provide the S-module with the ability to record error condi- tions associated with message transmission. The register may be interrogated by the M-module. Some bits in the register are reserved for application-specific uses (9.3).
2.3.16 class: See: commands, class of; messages, class of.
2.3.17 clear: To force the contents of one or more storage elements to the logic 0 state.
2.3.18 clock: A signal, the transitions of which (between the low and high logic level [or vice versa]) are used to indicate when a stored-state device, such as a flip-flop or latch, may perform an operation.
2.3.19 collision: The condition occurring when two MTM-Bus modules are simultaneously MTM-Bus driv- ers and are attempting to drive a MTM-Bus signal to complementary values (one driving logic 1, one driving logic 0).
2.3.20 commands, class of: One of the groups of MTM-Bus commands. Every MTM-Bus command is assigned to a command class (15.1).
2.3.21 Command Resource Unavailable (CRU) bit: A bi the Bus Error register of all S-modules. An S- module sets this bit to indicate that resources required to complete execution of a command were not avail- able and that the command was not executed.
2.3.22 Command Sequence Error (CSE) bit: A bit in the Bus Error register of all S-modules. An S-mod- ule sets this bit to indicate that the module has received a command that requires a previous enabling com- mand without receipt of such an enabling command (9.3).
2.3.23 command X, receipt of: Error-free receipt of the HEADER packet containing in its Command field the command code of X.
2.3.24 contend: To actively and simultaneously vie for the attention of the MTM-Bus Master module (said of a group or one or more S-modules).
2.3.25 critical control command: An MTM-Bus command that has significant effect on the operation of a module to a degree that, for added security, a message conveying such a command should be difficult to send unintentionally. This Standard provides that a message containing a critical control command has to be proceeded by an Enable Module Control (EMC) message (15.1; table 15.1; 16.10). If this procedure is not followed, a Command Sequence Error (1 1.9) will occur.
2.3.26 CRU: Acronym for “Command Resource Unavailable.” (See 2.3.21 .)
2-3
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
2.3.27 CSE bit: Acronym for “Command Sequence Error.’’ (See 2.3.22.)
2.3.28 Data Overrun Error @OR) bit: A bit in the Bus Error register of dl S-modules. An S-module sets this bit to indicate that the module has received input data from the M-module when the S-module was not ready to receive it (9.3).
2.3.29 DATA packet: Any packet other than a HEADER PACKET COUNT, or ACKNOWLEDGE packet.
2.3.30 DOR: Acronym for “Data Overrun Error.” ( S e e 2.3.27.)
2.3.31 ECL: Acronym for “emitter coupled logic.”
2.3.32 EMC: Acronym for “Enable ModuIe Control.”
2.3.33 error bit: A bit in a status register of an S-module that is associated with detection of some error detected by that S-module (1 1.1.1). Such bits may be found in the Bus Error register (9.3.1), the optional Module Status register (9.4.1), or in an Additional Status register (9.5.1). Error bits of the Bus Error register affect the value of the BSE bit of the Slave Status register (9.2.1). Error bits of the optional Module Status register or of an Additional Status register are permitted to affect the value of either the BSE bit or EVO bit of the Slave Status register.
2.3.34 Event Occurrence (EVO) bit: A bit in the Slave Status register of every S-module that is set by the S-module when a module-application-related condition requiring an interrupt has occurred (9.2).
2.3.35 EVO bit: Acronym for “Event Occurrence.” ( S e e 2.3.34.)
2.3.36 falling edge: The transition from a logic ane to logic zero.
2.3.37 fsm: Acronym for “finite state machine.”
2.3.38 HEADER packet: A packet originating in the MTM-Bus Master that is the first packet of an MTM- Bus message, The HEADER packet includcs an address and a command field. The address identifies which S-module(s) are to interpret and act upon the command contai
2.3.39 IBIT: Acronym for “initiated built-in test.”
2.3.40 Idle Interrupts Enabled (IIE) bit: A bit in the Slave Statws register of every S-module that is set to indicate that the S-module may generate an intempt during S-idle slates (9.2).
2.3.41 idle state: Any Link Layer Controller state the name of which begins with the uppercase letters “IDLE’ (6.1.1; 7.1.1). Such states in the MTM-Bus Master Link Layer Controller are called M-idle states and in the MTM-Bus Slave Link Layer Controller are called S-idle states.
wishin the command field (5.2).
2.3.42 IIE: Acronym for “Idle Interrupts Enabled.” (See 2.3.40.)
2.3.43 ILC: Acronym for “Illegal Command.” (See 2.3.44.)
2.3.44 Illegal Command (ILC) bit: A bit in the Bus Error register of all S-modules. An S-module sets this bit to indicate that the module has received an illegal command (9.3; 16.17).
2.3.45 inactive: When referring to an output driver (e.g., in the phrase “an inactive driver”), this term describes the mode in which the driver is not capable of determining the voltage of the network to which it is connected.
2-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
2.3.46 Incorrect Packet Count (IPC) bit: A bit in the Bus Error register of all S-modules. An S-module sets this bit to indicate that, with respect to a just completed message transfer, either the S-module has received a request for an ACKNOWLEDGE packet and was not given the opportunity to send it or, in the case of an S-module in which the packet counting option is implemented (14.2.1), that it received a different number of packets than was specified in the PACKET COUNT packet (9.3).
2.3.47 interoperable: Said of two modules indicating that they may both be placed on the same physical MTM-Bus without causing errors of operation.
2.3.48 interchangeable: Said of two modules that, although possibly of different design, perform identical functions and have identical interface characteristics.
2.3.49 Illegal Port Selected (IPS) bit: A bit in the Bus Error register of all S-modules. An S-module sets this bit to indicate that the module has received a command addressed to an unsupported port (9.3).
2.3.50 IPC: Acronym for “Incorrect Packet Count.” (See 2.3.46.)
2.3.51 IPS: Acronym for “Illegal Port Selected.” (See 2.3.49.)
2.3.52 least significant bit (lsb): The bit having the smallest effect on the value of a binary numeral; usually the right-most bit in figures.
2.3.53 least significant word (lsw): In a multiword representation of a binary number, the word containing the lsb of that number.
2.3.54 logic 0 (logic zero): The lowest voltage value of the two logic levels on an active-high signal and the highest voltage value of the two logic levels on an active-low signal.
2.3.55 logic 1 (logic one): The highest voltage value of the two logic levels on an active-high signal and the lowest voltage value of the two logic levels on an active-low signal.
2.3.56 lsb: Acronym for “least significant bit.” (See 2.3.52.)
2.3.57 Isw: Acronym for “least significant word.” (See 2.3.53.)
2.3.58 Master-capable: Said of an MTM-Bus module that is an S-module at a given time, but contains appropriate circuitry so that it may be converted by system control to an M-module if required.
2.3.59 Master Controller state: A state of the fsm (figure 6-1) required of M-modules that controls M-module Link Layer behavior with regard to message transmission.
2.3.60 M-Controller: Abbreviation for “MTM-Bus Master Link Layer Controller.”
2.3.61 MFS bit: Acronym for “Module Fail Status.” (See 2.3.72.)
2.3.62 message: A set of packets starting with a HEADER, consisting of that HEADER and all (ACKNOWLEDGE and DATA) packets transmitted as the immediate consequence of the command in that HEADER, and terminating when the M-module returns to the IDLE Master Controller state.
2.3.63 messages, class of: A group of messages having in the Command fields of their respective HEADER packets command codes of commands belonging to a single class of commands (table 15-1). The name, C, of a class of messages is the same as the name of the class of commands that defines the class C.
2-5
IEEE Std 11 49.5-1 995
4 MFM-6us +
IEEE STANDARD FOR MODULE TEST AND
MTM-BU
Application interface ~ Logic
2.3.64 messages, species of: A group of messages having in the Command fields of their respective HEADER packets a common command code (table 15-1). The name, S, of a message species is the same as the name of the command that defines the message species.
2.3.65 MICT Acronym for “Module U0 Control and Test” (clause 19).
2.3.66 MIST Acronym for “Module Initialization and SeLf-Test” (clause 18).
2.3.67 M-module: Abbreviation for MTM-Bus Master module.
NOTE-An MTM-Bus module consists of MTM-Bus intetface logic and inodule application logic.
Figure 2-1-MTM-Bus module
2.3.69 module address: An eight-bit 8. a?
2.3.70 Module Fail Status (MFS) bit: A I:ii i r t l!ic S1;ti-L: Simiis r q i s l ~ r ( ~ l ’ c ~ a y S-module that is set by the S-module when the module’s built-in I.+! Iias !%led (ir is cttl-rcn~.ly cxeciaitig (9.2).
2.3.71 Module Status register: A status register thar4s recommended to be implemented in the MTM-Bus interface circuitry of every S-module. The bits in this register are defined by the manufacturer of the MTM- Bus interface circuitry of an S-module. ‘l’lic IS (4 s:xIi ii r~yislci- itiaj serve to record error-condition detec- tion or the module’s application-related it:tlli!: f0.4j.
2.3.72 most significant bit (msb): The bit having the greatest effect on the value of a binary numeral; usu- ally the left-most bit in figures.
2.3.73 most significant word (msw): In a multiword representation of a binary number, the word containing the msb of that number.
2.3.74 msb: Acronym for “most significant bit.”
2.3.75 MSBO; MSB1: Acronyms for “multicast select bit 0” and “multicast select bit 1.”
2.3.76 MSD: Acronym for “MTM-Bus Slave Data.”
2.3.77 msw: Acronym for “most significant word.” (See 2.3.76.)
2-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
2.3.78 MTM-Bus: A serial, backplane, test and maintenance bus, consisting of one or more logic boards, that can be used to integrate modules from different design teams or vendors into testable and maintainable subsystems, as specified in this Standard.
2.3.79 MTM-Bus interface logic: The portion of a module that is designed for the purpose of MTM-Bus- compliant communication and through which takes place all the communication between the given module and any other on a given MTM-Bus implementation (7.2). MTM-Bus interface logic need not be defined on the basis of physical package boundaries.
2.3.80 MTM-Bus Master: The module in control of the MTM-Bus. This is the module that, at a given time, is sourcing MCTL and MMD.
2.3.81 MTM-Bus mastership: Property of being the current MTM-Bus Master module.
2.3.82 MTM-Bus Slave: An MTM-Bus module that cannot command actions of other modules on the bus, but that may be selected by the MTM-Bus Master module to participate in a message.
2.3.83 multicast: A mode of operation in which the M-module transmits data simultaneously (i.e., during a single message) to a predefined subset of the -modules currently connected to the bus. Also, a message transmitted in this mode.
2.3.84 multicast select bit 0; multicast select bit 1 (MSBO MSBl): Those bits in the Slave Status register of every S-module by means of which the S-module is programmed to be a member of one of the four possi- ble multicast select groups.
2.3.85 multicast select group: A group of S-modules that may be addressed simultaneously in a multicast. Four such groups are possible. Each has an address defined by this Standard (3.3). The multicast select group of an S-module is programmable. See also: multicast select bit 0; multicast select bit 1 (MSBO; MSB 1).
2.3.86 multidrop: Said of the configuration of a bus with a single shared medium segment that allows one or more of its module connectors to be unoccupied without disturbing bus operation.
2.3.87 non-NULL DATA packet: A DATA packet other than a NULL packet.
2.3.88 null DATA packet: See: NULL packet.
2.3.89 NULL packet: A special type of DATA packet containing a data field entirely filled with logic zeros and a parity bit equal to logic one (5.6). Syn: null DATA packet.
2.3.90 off-line: Used to describe an MTM-Bus module when it is in a mode such that it will not respond to state transitions on MTM-Bus signals whether or not the module is connected to the bus. Also used to describe such a mode.
2.3.91 packet: A 17-bit unit of data consisting of a 16-bit word plus 1 parity bit.
2.3.92 PACKET COUNT packet: A packet by means of which an M-module conveys to addressed S-modules the number of packets to follow in the current message. S-modules may or may not include the ability to use the data in this packet (5.4).
2.3.93 packet latency: During a sendreceive message, the number of packet transfers by which the first non-NULL DATA packet returned by the addressed S-module lags the first non-null DATA packet transmit- ted by the M-module.
2-7
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
2.3.94 packet pair: Two packets, one transmitted by the M-module and one by an S-module, such that the last 14 bits of the M-module-originated packet are transmitted simultaneously with the first 14 bits of the S- module-originated packet.
2.3.95 Parity Error (PRE) bit: A bit in the Bus Error register of all S-modules. An S-module sets this bit to indicate that the module has detected a Parity Error on a DATA packet received (9.3).
2.3.96 participate: With regard to the action of an S-module during message transmission, to exe command contained in the HEADER packet of the current message and return packets as required by that command and by the state of the Acknowledge bit in the HEADER packet. The handling of some errors may cause an S-module to cease to participate in a message (clause 1 l w . g . , by ceasing to execute the current command, by returning NULL packets when data is expected, by driving a constant value on the MSD sig- nal without regard to packet transmission timing, etc.
2.3.97 Pause Interrupt Enabled (PIE) bit: A bit in the Slave Status register of every S-module that is set to indicate that the S-module may generate an interrupt during the PAUSE Slave Controller state when the S- module is addressed (9.2).
2.3.98 PIE: Acronym for “Pause Interrupt Enabled.” (See 2.3.101.)
2.3.99 port: A source or destination of d an S-module (clause 21). A port may be to a module, or some other mechanism t
r class command~into andor out of
a Data Transfer class command.
2.3.100 PORT ID packet: The first D ta Transfer class message. This packet
2.3.101 Port Transfer Error: A port-specific error command or data to/from a currently selected port.
2.3.102 Port Transfer Error (PTE) bi
e failure with relation to transmission of
all S-modules. An S-module sets
stands for “Port Transfer Error” (9.3).
2.3.103 PRE: Acronym for “Parity Error.” (See 2.3.99.)
2.3.104 PTE: Acronym for “Port Transfer Error.” (See 2.3.106.)
2.3.105 release: To cease to assert a logic 1 on a bus signal line. (One module’s releasing a signal line pro- duces a change in value of the signal line only if no module is asserting the signal.)
2.3.106 released: Having a value equal to logic 0 (said of any signal). Equivalently, in the case of an MTM- Bus signal line, not asserted by any module on the bus.
2.3.107 reset: When describing the operating status of an S-module, the state of the S-module’s Status reg- isters defined by 9.2.lb, 9.3.lb, 9.4.1b, and 9.5.1b-the state of these registers produced by execution of the Reset Slave Status command (16.3.1).
2-8
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
2.3.108 response: In the context of message transmission, the set of packets sent by an S-module during a single message. In the context of the operation of S-modules, an S-module’s action that is a direct conse- quence of the command most recently received by that S-module.
2.3.109 rising edge: A transition from a logic zero to a logic one. (See tLH in 4.4 and in figure 4-4.)
2.3.110 S-Controller: Abbreviation for “MTM-Bus Slave Link Layer Controller.”
2.3.111 S-module: Abbreviation for “MTM-Bus Slave module.”
2.3.112 SBIT: Acronym for “Start-up Built-in Test” (performed at power-up or after resets of a module).
2.3.113 SDF: Acronym for “Slave Data Fault.” (See 2.3.125.)
2.3.114 select: To identify and fix (for the duration of the current message) a port to which data of a Data Transfer class message are to be directed.
2.3.115 sequence: A set of bits, packets, or messages ordered in time and that are, or that are intended to be, transmitted consecutively without interruption.
2.3.116 set (used as a verb): To force the contents of one or more storage elements to a logic 1.
2.3.117 simple message: An MTM-Bus message that consists of no more than a HEADER and, optionally, an ACKNOWLEDGJYPACKET COUNT packet pair.
2.3.118 singlecast: A mode of operation in which the M-module transmits data to a single S-module. Also, a message transmitted in this mode.
2.3.119 Slave Busy (BSY) bit: A bit in the Slave Status register of every S-module that is set by the S-mod- ule when the application logic of the S-module is executing a previously transmitted MTM-bus instruction or is executing its power-up sequence.
2.3.120 Slave Controller state: A state of the fsm (7.1.1 Link Layer behavior during message transmission to the module.
quired of S-modules that controls S-module
2.3.121 Slave Data Fault (SDI?) bit: A bit in the Bus Error register of all S-modules. An S-module sets this bit when it is transmitting on the MSD signal and detects a fault on that signal.
2.3.122 Slave Status register: A status register that is required to be implemented in the MTM-Bus inter- face logic of every S-module. Bits in this register are used to record such items of module status as interrupt enable status, whether an error condition has O C C U K ~ , whether a module application-related error has occurred, whether the module has failed its Built-In Self Test, etc.
2.3.123 SSE: Acronym for “State Sequence Error.” (2.3.128.)
2.3.124 State Sequence Error (SSE) bit: A bit in the Bus Error register of all S-modules. An addressed S - module sets this bit to indicate that the S-module’s Slave Link Layer Controller has entered the ERROR Slave Controller State (9.3).
2.3.125 status bit: A bit used to indicate a non-error condition important to S-module operation. Status bits are located in an S-module’s Slave Status register (9.2.1) and Bus Error register (the BMR bit) (9.3.1) and may be located in the optional Module Status register (9.4.1) or an Additional Status register (9.5.1). Status bits in the Module Status register or in an Additional Status register are permitted to affect the value of the EVO bit of the Slave Status register.
2-9
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
2.3.126 status register: A register in an S-module by means of which current operating conditions of the S- module (e.g., interrupt enabled, module pass/fail status, multicast address of the S-module, etc.) and event occurrence (e.g., detection of an error condition during transmission of a message) can be recorded either for later interrogation by the M-module or to record the necessity of particular S-module activity at a later time.
2.3.127 transfer: The successful movement of a bit or bits between an MTM-Bus Master module and one or more modules co-connected by the MTIvl-Bus.
2.3.128 transfer state: A state of a Link Layer Controller the name of which begins with the letters “XFER’ (6.1.1; 7.1.1). Such states in the MTM-Bus Master Link Layer Controller are called M-transfer states and in the MTM-Bus Slave Link Layer Controller are calEed S-transfer states.
2.3.129 TTL: Acronym for “transistor-transistor logic.”
2.3.130 uniquely addressed: Said of an MTM-Bus S-module participating in a singlecast.
2.3.131 word: An ordered set of 16 bits operated on as a unit. The most significant bit is labeled bit 15 and the least significant bit is labeled bit 0.
NOTE-When a word of data is embedded in a MTM-Bus packet, bit <o> of the data word is placed in bit <1> of the 17-bit packet. See clause 5.
2.4 References
The following publications shall be used in conjunction with this Standard. When standards are referred to in this document, the latest revision shall apply:
IEEE Std 100-1992, The New IEEE Standard Dictionary of Electrical and Electronic Terms.2
IEEE Std 802-1990, IEEE Standards for Local and Metropolitan Area Networks: Overview and Architec- ture.
IEEE Std 1149.1-1990, IEEE Standard Test Access Port abd Bbundary-Scan Architecture (Includes IEEE Std 1149.1a-1993).
IEEE Std 1149.1b-1994, Supplement to EEE Sid 1140.1-1990. IEEE Standard Test Access Port and Boundary-Scan Architecture.
21EEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,
3SAE publications are available from the Society of Automotive Engineers, 400 Commonwealth Drive, Warrendale, PA 15096, USA. NJ 08855-1331, USA.
2-10
MAINTENANCE BUS (MTM-BUS) PROTOCOL
M-module
IEEE Std 1149.5-1995
S-module ... S-module
3. MTM-Bus architecture
A A A
] A
Master Data (MMD)
Slave Data (MSD)
Pause Request (MPR)
This clause defines the component signals of the MTM-Bus, the interconnection of modules on the bus, the limitation of the number of such connections, and the conventions for addressing S-modules connected to the MTM-Bus. The MTM-Bus is described as a backplane bus; however, it may be used with cable or other connections that allow compliance with the MTM-Bus Physical Layer rules in clause 4.
P
3.1 MTM-Bus signals and interconnection of MTM-Bus modules via these signals
I Control (MCTL) I
3.1.1 Specifications
I
(a) The MTM-Bus shall include an MTM-Bus Control signal, MCTL, that is unidirectional from the current M-module to all connected S-modules.
NOTE-Since some S-modules may be master capable, we have to distinguish the current M-module as the one to which these specifications apply. In later clauses, we will simply say the M-module to refer to the current M-module.
(b) The MTM-Bus shall include an MTM-Bus Master Data signal, MMD, that is unidirectional from the current M-module to all connected S-modules.
(c) The MTM-Bus shall include an MTM-Bus Slave Data signal, MSD, that is unidirectional from each connected S-module to the current M-module.
(d) The MTM-Bus shall include an MTM-Bus Clock signal, MCLK, that is unidirectional from the bus clock source to the M-module and connected S-modules.
(e) All MTM-Bus signal inputs and outputs on a MTM-Bus module shall be dedicated connections (i.e., such module pins shall be used for no other purpose).
(f) The MMD, MSD, MPR, and MCTL signals shall be connected to all modules in a multidrop con- figuration (i.e., all driversheceivers for each of the four signals shall share a single physical con- nection as in figure 3-1).
Clock Source
Clock (MCLK)
NOTE-The MTM-Bus includes the Master Data (MMD), Slave Data (MSD), Control (MCTL), Clock (MCLK [free-running and externally sourced in this example]), and recommended Pause Request (MPR) signals.
Figure 3-1-Backplane MTM-Bus signals
3-1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Recommendations
(g) The MTM-Bus should include an MTM-Bus Pause Request signal, MPR, that is unidirectional from connected S-modules to the current M-module.
3.1.2 Description
Dedicated module connections for MTM-Bus signals (3.1.1e) are required to all0 of mandatory features of this Standard. The five signals that make up the MTM- The MPR signal is a recommended signal that can be used to simplify the use of the b posed of modules having a wide range of operational speeds
MCTL-The M-module’s link-layer protocol uses the MTM-Bus Control signal ations over the MTM-Bus MMD and MSD signals. When the M O L signal is asserted, either a data transfer is occurring or there is an error condition. The MCTL signal is released during a pause in the transmission of a message, during the idle period between the transmission of messages, or in error conditions.
MMD-The MTM-Bus MMD signal is used to serially transfer control or data from the M-module to S- modules. Whether the value of the MMD signal is intended to convey control or data is dependent upon the M-module’s Master Controller state.
MSD-The MTM-Bus MSD signal is used to transfer serial data from S-modules to the M-module using a logical-OR connection. The MSD signal is used for S-module data transfer and may be used to indicate an interrupt during pauses in message transmission and or in the idle periM between the transmission of mes- sages.
MCLK-The MTM-Bus MCL ignal is used to synchronize MTM-Bus. All other MTM-Bus signals change value only a MTM-bus modules capture these other signal values only at the falling edge of the MCLK signal.
MPR-The MTM-Bus MPR signal is used so that addressed S-modules may request the M-module to expand the pause between packet transfers during transmiss message. This mechanism can be used to eliminate errors caused by the M-module sendingepackets t for a receiving S-module or by an S - module’s not being ready to return data. Without the capability offered by the MPR signal, occurrence of such an error would cause an S-module to generate an interrupt to the M-module. This, in turn, could cause the M-module to abort the current message and investigate the cause of the interrupt. In some cases, this might lead to extremely lengthy message transfer times, even for very short messages.
een modules on the MCLK signal, and
3.2 General architecture and MTM-Bus mastership
3.2.1 Specifications
(a) At any time that any module among the set of modules connected to the MTM-bus is operating as an M-module, exactly one of them shall operate as an M-module.
(b) The MTM-Bus shall provide logical addressing for up to 250 modules.
Permissions
(c) To improve bus availability and fault tolerance, MTM-Bus mastership may be transferred to a Master-capable S-module.
3-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
S-module 3 S-module 1 S-module 2
I€€€ Std 1149.5-1995
S-module 250 ...
3.2.2 Description
The basic bus topology is shown in figure 3-2. In this diagram, a single M-module is depicted with a multi- drop connection to as many as 250 S-modules. The MTM-BUS modules need not necessarily map one-to-one to the physical partitioning of the system. It is allowable to define the system topology such that a single “module” actually consists of multiple logic boards or that multiple “modules” may reside on a single logic board.
Should system diagnostic routines detect a malfunction in the M-module of a particular implementation of the MTM-Bus, system software may reconfigure the system by deactivating the current M-module and mak- ing a Master-capable S-module the new M-module. If a system’s S-modules are designed in such a way as to make this possible, then much of the testing function can be preserved in the face of M-module failure or degradation.
3.3 S-Module addressing requirements
3.3.1 Specifications
Rules
(a) In a given MTM-Bus implementation at a given time, any S-modules
(i) shall have at least one module address that is an eight-bit binary number between ‘0’ and ‘F9’ HEX;
(ii) shall include in its manufacturer’s documentation a description of the mechanism by which that address is, or shall be, defined.
(b) In a given MTM-Bus implementation at a given time, no two S-modules connected to that MTM- Bus may have the same module address.
NOTE-This rule implies that generic or off-the-shelf S-modules have to have one or more module addresses that can be fixed by an user during assembly of a system (e.g., by the operation of switches or by program- ming).
(c) An S-module’s module address shall be accessible to (i.e., readable by) the MTM-Bus interface cir- cuitry of that module.
3-3
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
An S-module shall be considered addressed only in one of the following conditions:
(i) The given S-module is able to determine its module address unambiguously; and the HEADER packet (5.2) received without detection of an e m r at the stxt of the current message contains either the S-module’s module address, the broadcast address (’FB’ HEX), or the multicast address (‘FC’, ‘FD’, ‘FE’, or ‘FF’ HEX) corresponding to the module’s current multicast group (9.2; 16.5.la).
(ii) The given S-module is unable to determine its module address unambiguously; and the HEADER packet received without detection of an error aE the start of the current message con- tains either the amnesia address (‘FA’ HEX), the broadcast address (‘FB’ HEX), or commands addressed to the multicast address (‘FC’, ‘FJY, ‘FE’, or ‘Fl? HEX) corresponding to the S- module’s current multicast group.
NOTE-It may be unwise to broadcast messages when more than one S-module in a system are responding to the amnesia address. No S-module can become addressed as a result of receiving an HEADER packet if an error such as bad parity in that !3EADER packet (5.2.1; 11.5.1) or a State Sequence Error (7.1; 11.6.1) is detected.
At the time a system including an MTM-Bus implementation is powered up, no S-module shall be addressed.
An S-module shall be considered “uniquely addressed” only after
(i) a HEADER packet has been received that contains the S-module’s module address module is able to determine its module address unambiguously;
8
(ii) a HEADER packethas been received that contains the amesia“address, and the S-module is not able to detemiiiiz ils I T W ~ L I ~ C ircldress unambiguously (and is therefore responding to the amnesia address (3.3.1 r i ( i i ) ; 33.111).
NOTE-Despite the fact that there may be n:::Mp!; S ifM&&’s that can be addressed by the amnesia address, they all will behave as if they are unique11 ; I I ! I ~ : * - . v I . In p command addressed to ‘FA’ HEX.
An S-module shall respond to commands when and only when it is addressed.
NOTES 1-This rule (taken together with 3.3.ldj iirrplies Ihat an Y- biguously can never execute commands sent to the amnesia address (‘FA’ E X ) .
2-An S-module may take its MTM-Bus interface off-line during Start-up Built-In Test (SBIT) (18.2.lg) for local testing of the interface circuitry (the only time this is permitted). This means that the S-module might not receive commands sent during the self-testing period. The M-module may poll an S-module, requesting an ACKNOWLEDGE packet, to determine when an S-module is back on-line after self-testing and ready to receive MTM-Bus commands.
far, they will return data if s
e hat can defennine its module address unam-
Recommendations
(h) An S-module should be able to detect the condition of being unable to determine its module address unambiguously.
NOTE--To utilize the safety features supplied by the amnesia address, this recommendation has to be imple- mented. During the development of this Standard, addressing errors were observed in systems using prototype versions of this Standard; these errors could have been avoided and related faults d 3.3.lh and the amnesia address been specified at the time and implemented. Altern security (such as appropriate Hamming distance between addresses) may be tolerable in a sparsely populated MTM-Bus address space, but might have a disadvantage because of not being supported by a standard.
3-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(i) The formatlencoding of the module address as set in a given S-module during system assembly should provide for single-bit error detection when the address is read.
NOTE-For example, to increase the probability of an S-module’s detecting an error in the accessing of its module address, the module manufacturer could add an additional, parity bit to the module address.
0) The module address of an S-module with a programmable module address should be ‘FA’ HEX when it is purchased (i.e., prior to programming of the module address).
NOTE-Details of the manner in which an S-module’s module address is programmed have to be fully docu- mented by the module’s manufacturer (22.1. Ib).
Permissions
(k) Module addresses may be implemented by a variety of means, including
(i) on-module firmware
(iii) DIP switches
(iv) discrete pins on the backplane
3.3.2 Description
Each S-module is to be assigned an eight-bit address. The use of eight bits allows for a set of 256 addresses including 250 single module addresses (‘0’ through ‘F9’ HEX), one amnesia address (‘FA’ HEX) for use by an S-module that has lost access to its module address, one broadcast address (‘FB’ HEX), and four multi- cast addresses (‘FC’, ‘FD’, ‘FE’, and ‘FF’ HEX). An S-module is considered to be addressed (and thus allowed to execute the current MTM-Bus command) if it has received (in the most recently transmitted HEADER packet) its module address (or the amnesia address when appropriate), the broadcast address, or the multicast address that matches its current multicast select group. An S-module is considered uniquely addressed if it has received its module address or the sia address in the most recently transmitted HEADER packet. Whether an S-module is “addressed” or “uniquely addressed” influences the manner in which it responds during an MTM-Bus message.
If an S-module is unable to access its module address (e.g., due to a module address parity error, etc.), the S- module in question can respond only to commands sent to the amnesia address (‘FA’ HEX) or to any com- mand sent to the broadcast address or the address of the S-module’s current multicast group. The amnesia address provides the possibility of limited system diagnosis based on data recovered from S-modules unable to access their unique module addresses. Some data can be recovered from such modules using the amnesia address because the modules will act as though uniquely addressed. Diagnosis might begin by directing the M-module to read the module status of the module with address ‘FA’ HEX. If there is an “all zero” response, then no S-module is responding and, hence, unless more serious failures have occurred, no S-module has self-diagnosed an address fault. If multiple S-modules respond to ‘FA’ HEX (i.e., become addressed by a given message) and an ACKNOWLEDGE packet is required, the collision-error handling of the S-modules (1 1.7.1) can (at least sometimes) reduce the number of modules that remain addressed after ACKNOWL- EDGE packet transmission to as few as one.
Note that at any given time all modules not in the group that respond to the amnesia address may be segre- gated in one multicast group. Then this group’s address may be used as a substitute for the broadcast address. To simplify software design, it may be wise to have such a multicast group address established as
3-5
IEEE Std 114951995 I€€€ STANDARD FOR MODULE JEST AND
equivalent to the broadcast address from the outset and simply remove amnesiac modules to another multi- cast group if and when they are detected.
Each S-module has to respond to at least one of the 250 module addresses (or to the amnesia address) so that it can be addressed by the M-module. An S-module’s unique module address may be provided to the MTM- Bus test interface on the S-module by a variety of means including firmware, jumper wires, dual in-line package (DIP) switches, or discrete wires to the backplane. With any of these methods, an additional address parity bit should be provided to ensure that a given S-module’s MTM-Bus test interface will be able to detect the occurrence of single bit address faults and, consequently, will not respond to another S-module’s address in the event of such a fault.
3-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
4. MTM-Bus Physical Layer requirements
The MTM-Bus Physical Layer defined in this clause includes the definition of the electrical and timing requirements for the MTM-Bus signals. Precise electrical and timing requirements are not specified to allow for selection of bus transceivers most appropriate to a specific application.
In this and subsequent descriptions of MTM-BUS layer requirements, the requirements are divided into three categories: Those having to do with S-modules, those having to do with M-modules, and those that apply to both module types. The intent of this division is to make it easier for a potential designedmanufacturer of modules to separate the requirements for M-modules and S-modules.
4.1 Physical layer requirements independent of module type
4.1.1 Specifications
(a) All MTM-Bus signal drivers, excluding lhe driver of the MCLK signal, shall support a logical-OR operation such that if any module drives a logic 1 on such a signal, that signal will be forced to a logic 1.
NOTE-The MTM-Bus signals MCTL, MMD, MSD, and MPR may collectively use active-lowhegative logic levels on the backplane. Such an implementation may be necessary in some technologies to obtain a log- ical-OR operation.
@) All MTM-Bus signal receivers shall interpret a logic 1 as actively driven.
(c) Signal drivers for all MTM-BUS signals shall be designed so that the simultaneous driving of logic 0 and logic 1 values by different modules on a given MTM-Bus signal shall not cause physical damage to any driver of that signal.
Recommendations
(d) The MTM-Bus signal drivers and receivers on a given MTM-Bus module should exhibit a high input impedance when that module is insufficiently powered for normal operation.
NOTE--This specification is a recommendation rather than a rule because there may be cases in which it is expected that all modules in a given implementation are always powered up. However, if this is not the case or if protection is desired in case of power supply failure, then following this recommendation may be very important.
4.1.2 Description
Logical-OR operation: Logical-OR operation on bus signals is required for a variety of reasons. The MSD signal requires logical-OR operation to make use of Contend for Bus command (16.4.1). Logical-OR opera- tion of the MPR signal is needed to allow one or more of multiple S-modules to request additional time in the PAUSE Slave Controller state during a broadcast or multicast message so that the slowest S-module may request an adequate number of cycles in the PAUSE Slave Controller state (8.3). Logical-OR operation on the MMD and MCTL signals may be used to allow transfer of MTM-Bus mastership from one M-module to another without potentially damaging collisions.
Selecting bus transceivers: The MTM-Bus Physical Layer may be customized to use bus transceivers from any number of logic families such as open-collector transistor-transistor logic (TIZ), backplane transceiver logic (BTL), and emitter coupled logic (ECL). The selection of a specific logic family may be influenced by
4- 1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
the length of the backplane, the number of expected loads, the bus frequency, noise immunity, cost, power, and available power supplies.
Logic ZeveZs: This MTM-Bus Protocol Standard does not provide detailed electrical and timing parameters for the modxle. Timing diagrams depict logic levels rather than voltage levels.
The bus signals MCTL, MMD, MSD, and MPR at the module interface may be implemented in a negative logic technology that supports logical-OR operation. Any modules that are intended to interoperate have to address the appropriate electrical parameters, including the logic level for these bus signals.
It is possible that the MCLK will be implemented in a different device technology than the other bus signals. The reasons are twofold
- MCLK does not require logical-OR operation, and - the other bus signals may experience ringing prior to settling before a clock
The MCLK signal has to make a clean transition through its threshold region to avoid inadvertent data driv- ing or 1atching.The MCLK logic level selection for the device technology may be based on an acceptable noise margin to avoid driving data inadvertently. A family of interoperable modules have to address the appropriate MCLK electrical parameters, including the logic levels.
-module Physical Layer requirements
4.2.1 Specifications
Rules
(a) The MMD and MCTL signal drivers of an M-module shdfbe active continuously during operation of the MTM-Bus.
(b) An M-module shall provide collisioderror detection circuitry on both MMD and MCTL signals. For each of these signals, the relevant circuitry in a given module, M, shall detect cases in which M's MTM-Bus driver of the signal is attempting to force the signal to the logic zero state when the logical-OR function of the bus (4.1. la) is resulting in a logic one value for the signal.
(c) The M-module shall have the capability to d e k t the value of, and respond to, the MPR signal.
(d) The M-module shall have the capability to detect the value of, and respond to, the MSD signal.
4.2.2 Description
See discussion of logical-OR operation in 4.1.2.
See discussion of collision-detection circuitry design options in 4.3.2.
4-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
4.3 S-Module Physical Layer requirements
4.3.1 Specifications
(a) S-modules shall provide collisioderror detection circuitry on the MSD signal connection. The rel- evant circuitry in a given module, M, shall detect cases in which M's MTM-Bus driver of the MSD signal attempts to force the signal to a logic zero when the logical-OR function of the bus (4.1. la) is resulting in a logic one value for the signal.
NOTE-Collision-detection circuitry plays a key roie in the Contend for Bus (16.4.1) and Verify BMR (16.12.1) sequences.
(b) The collisioderror detection function on the MSD signal of a currently addressed S-module shalI be enabled to set the SDF bit of the Bus Error register and release the MSD signal (1 1.7. la) only if the S-module is uniquely addressed and actively transferring a packet required in response to the current command with the exception of the ACKNOWLEDGE packet (5.3) being transferred in response to a Contend for Bus command (16.4.1) or a Verify BMR command (16.12.1).
NOTE--Timing constraints on collision-detection circuitry are implied by 11.7.la. Namely, it has to be possi- ble to detect a collision and release the MSD signal before the S-module in question can transmit another bit on MSD-before the first rising edge of the MCLK signal following the rising edge of the MCLK signal on which the collision occurred.
Recommendations
(c) The MPR signal should be implemented on all S-modules.
4.3.2 Description
Collision detection: Collision detection is needed both to detect bus errors and to allow an S-module to release its MSD signal when it loses Contend for Bus operations (16.4.1) or Verify BMR operations (16.12.1). As illustrated in figure 4-1, collision dctcction may be implemented by providing a receiver for each output driver and comparing the (internal module) value to be output on the bus and the current value on the bus. This function has to be gated such that collisions are only reported when the output of the driver is enabled and the packet being transferred is not the ACKNOWLEDGE packet transferred in response to a Contend for Bus command.
It is possible to comply with the IEEE Std 1149.5 requirements for collision detection while using discrete bus transceivers or electrical level translators. As illustrated in figure 4-2, the component that provides sup- port for the collision detection may have two discrete pins for each bus output. Separate electrical-level translators can then be connected to provide the logical-OR drive and to sense the actual bus value. With this approach, a single component that supports the MTM-Bus protocol, perhaps with TTL electrical levels, could be used with off-the-shelf transceivers to support open-collector TTL, ECL, BTL, or other backplane electrical levels.
See discussion of logical-OR operation in 4.1.2.
When an uniquely addressed S-module is transmitting a packet in response to the command contained in the current message [other than an ACKNOWLEDGE packet being sent in response to a Contend for Bus com- mand (16.4.113, the MTM-Bus interface circuitry of the S-module has to record detection of a collision on the MSD signal by setting the SDF bit of the S-module's Bus Error register (9.3).
4-3
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Taking drivers off--line: When an S-module is involved in start-up self-testing it may take its MTM-Bus interface off-line (18.2.lg).
L 7
I
Output Enable
MTM-BUS Output Signal
System Pin h - ~
v EN
I D
collision has occurred is cap- li - 1D
> c1 - &
=I
MCLK - Collision 4
NOTE-This example circuit compares the logic value being driven with the logic value currently on the bus. A box con- taining "=1" is the IEEE standard symbol for an XOR gate.
Figure 4-14ollision detection
1
DrivedReceiver
-1
NOTE-Separate off-the-shelf drivers and rcceivers can bo used to cusbmize a single MTM-Bus interface device for mul- tiple Physical Layer protocols.
Figure 4-2--Sus transceivers
4.4 MTM-Bus timing requirements
The following symbols are used in specifying timing parameters and as labels in figures 4-3 through 4-5:
to
tl
TIM
ToM
is the time that MCLK is logic 0 per cycle is the time that MCLK is logic 1 per cycle
is the minimum operable tl for an MTM-Bus module or MTM-Bus interface device, M is the minimum operable to for an MTM-Bus module or MTM-Bus interface device, M
4-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
tLH tm
tc
is the duration of MCLK rising edge transition is the duration of MCLK falling edge transition is the MCLK cycle time ( ~ L H + tl + tm + to)
NO-The transition times tLH and tm can be determined only for a given system. These times are not considered a part of tl or to and have to be accounted for in the selection of tc.
TcM T L H ~ is the minimum operable tLH for an MTM-Bus module or MTM-Bus interface device, M TmM is the minimum operable fm for an MTM-Bus module or MTM-Bus interface device, M
tp tcsMpN is the clock skew as measured between the MTM-Bus signal driver, M, and the MTM-Bus signal
TCoM is the clock-to-output time for an MTM-Bus signal driver, M
T~~ is the set up time for an MTM-BUS signal receiver, M
ThM is the hold time for an MTM-Bus signal receiver, M
is the minimum operable tc for an MTM-Bus module or MTM-Bus interface device, M
is the maximum system backplane propagation and settling time
receiver,N ~
Note that timing parameters of MTM-Bus modules, MTM-Bus interface devices, and individual drivers on MTM-Bus modules are designated in a TzM format. Note that there is a value of TzM specific to each of MPR, MMD, etc., for a given module. Timing parameters for a given system under discussion are in the ty format.
4.4.1 Specifications
Rules
(a) The MTM-Bus Clock (MCLK) signal shall be a single-phase clock.
(b) In the implementation of the MCLK signal, a 1 c one shall be the more positive of the two voltages; and a logic zero, the least pod
(c) The manufacturer of an MTM-Bus module or MTM-Bus interface logic, M, shall document TcM (minimum operable value for tc), TIM (minimum operable value for tl), and ToM (minimum operable value for to).
(d) An MTM-Bus module or MTM-Bus interface device, M, shall be compliant to this Standard for all values oft,, f l , and to where t, 2 TcM, t l 2 TIM, and to 2 ToM.
(e) Stored-state devices contained in MTM-Bus interface logic shall retain their states indefinitely when the signal applied to MCLK is stopped at a logic 0 or a logic 1.
(f) MTM-Bus signal outputs shall change state only following a rising edge of the MCLK signal.
(g) A11 MTM-Bus signal inputs shall be latched following each falling edge of the MCLK signal.
(h) The manufacturer of an MTM-Bus module or MTM-Bus interface device including an MTM-Bus signal driver, M, shall document ThM, TcoM (figure 4 4 , and TsM (figures 4-3 and 4-4).
4-5
IEEE Std 1149.5-1995
C O M
- 1D -> c1
rising-edge triggered
IEEE STANDARD FOR MODULE TEST AND
bus signal with propagation delay GN
k 1D -
-> c1 falling-edge triggered
Recommendations
(i) For any MTM-Bus signal driver, M, the module timing parameters TcoM, TsM, and ThM should be minimized.
NOTE-This will support performance IIliiximization for an hTkM-Bus implementation to which the given module is connected.
(j) In any MTM-Bus module, M, the module timing parameter TOM should be minimized.
NOTL-This will allow the MCLK signal for systems containing the given module to be held = logic 1 for as long as possible to support secure backplane propagation.
Permissions
NOTE-An MTM-Bus signal output drives new data on the rising edge of MCLK, and an MTM-BUS signal input latches data on the failing edge of MCLK.
Figure 4-3-Data transfer
A timing diagram showing the MCLK and another MTM-Bus signal waveform at both a transmitter and a receiver are illustrated in figure 4-4.
To assess module hold requirements, consider the worst-case condition-that in which the clock at the receiver (MTM-Bus module iV) trails the clock at the driver (MTM-Bus module M> as illustrated in
4-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
figure 4-5. The system parameter to has to be chosen such that the falling edge does not latch new data at a time when the relevant signal value is changing. For any MTM-Bus signal output, M, and signal input, N , connected in a particular implementation of the MTM-Bus, the relevant system timing relationship is char- acterized by
to 2 ThN + tcsMiN
MCLK at Driver (M)
Signal at Driver (M)
Signal at Receiver (N)
MCLK at Receiver (N)
NOTE-This timing diagram shows the transitions of MCLK and her MTM-Bus signal at both the signal driver (on MTM-Bus module M) and signal receiver (on MTM-Bus module N) in the worst-case propagation situation-where the clock at the receiver leads the clock at the source. In every bidirectional data transfer, operation in one of the directions will fit the worst case just described.
Figure 4-+Data transfer timing
For a given MTM-Bus implementation in a given system, the MCLK waveform will have to be adjusted so that worst-case timing requirements for the connected MTM-Bus interface devices [equation (l)], the worst- case system propagation budget [equation (2)], and the worst-case module hold time requirement [equation (3)] are not violated.
tc 2 max (Tcx : X is a module or interface device connected to the bus) (1)
tl 2 max (Tcox + tp + qy + tC$' : X is a signal output and Y is a connected signal input) (2)
to 2 max (Thy+ tC$' : Xis a signal output and Y is a connected signal input) (3)
In addition, the system timing parameters cannot violate the worst-case module timing parameters.
4-7
IEEE Std 114951995
MCLK at Driver (M)
IEEE STANDARD FOR MODULE TEST AND
$0 - &
tl 2 max (TIM : M is a module connected to the bus)
to 2 max (ToM : M is a module connected to the bus)
tc 2 max (TcM : M is a module connected to the bus)
Signal at Driver (M)
Signal at Receiver (N)
MCLK at Receiver (N)
As long as the system MCLK waveform parameters tl, to, and tc meet the relationships described in the present clause, system timing requirements will be met. This method for specifying the MCLK waveform requires the bus interface to operate over a range of MCLK frequencies from as low as may be desired by a user to a documented maximum.
DATA BiT i DATA BIT i-1 x A DATA BIT i DATA BIT i-1
.c= +
NOTE-This MTM-Bus timing diagram shows the transitions of the clock and another MTM-Bus signal at both the signal driver (M) and signal receiver (N) in the worst-case hold lirne sihiation. In this case, the clock at the receiver trails the clock at the source, propagation delay is zero, and clock to output dclay for Mis zero. The time to has to equal or exceed the sum of the clock skew and the hold time of N.
Figure 4-5-Hold time requirement -
Pe$omzance requirements: Although minimum performance requirements for an MTM-Bus module, M , are not specified, it is recommended that TIM and TO“ be minimized to allow greater bandwidth if required by a system. An MCLK waveform has to be observed on the system backplane to ensure that module TIM and T~~ requirements are met.
Integration risk: All MTM-Bus timing relationships involve t l , to. and tc. Thus decreasing the M quency (thereby increasing t l , to, and tc) will alleviate potential timing violations. In addition, the MTM-Bus dual-edge timing approach encourages design and use of MTM-Bus modules employing technologies that support “low” values of TcoM, because this will tend to increase the backplane propagation budget.
NOTE-The dual-edge timing approach was adopted over a single-edge approach. In a single-edge approach, data are driven and latched on the same signal edge. In the worst case, the clock skew between a transmitting module, M , and receiving module, N-taMiN-has to be controlled to avoid latching data from a signal that is in transition. This condi- tion is characterized by tCsMjN 2 TCoM - ThN. Because the clock skew requirement in a single-edge system is independent of MCLK frequency, skew problems cannot be alleviated by reducing MCLK signal frequency. Implementations that reduce TcoM place tighter requirements on clock skew. In a dual-edge approach, worst-case module and backplane tim- ing constraints may always be alleviated by increasing tl or to (at the cost of reducing MTM-Bus bandwidth).
4- 8
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
Znteroperability: Because this Standard addresses module timing parameters while leaving the system parameters flexible, a set of modules with compatible electrical characteristics may be interoperable in a number of systems having differing backplane timing parameters. The MCLK waveform can be selected to meet the backplane propagation budget and the capabilities of the selected MTM-Bus modules.
NOTE-The SAE Avionics TM-Bus Interoperability Standard AS4765 has adopted this timing approach and is adding additional detailed timing and electrical requirements to support development and deployment of interoperable modules in the avionics environment.
Support for debugging an integrated system: Stored state devices contained in the MTM-Bus interface logic have to retain their state even when the MCLK signal is stopped (in either a “0” or “1” state) as detailed by rule 4.4.le. This requirement is made to allow debugging in a system integration environment in which the MCLK signal may be stopped for some reason (e.g., to permit an ATE test pattern load or to check signal values during error tracing). If state information or statuderror information in stored state devices in the MTM-Bus interface logic were not retained when the signal on MCLK is stopped, the debugging process would be severely complicated.
4-9
IEEE Std 1149.5-1995
5. MTM-Bus Link Layer: Packet requirements
All MTM-Bus messages consist of the transfers of 17-bit packets. The packet types include HEADER packet, ACKNOWLEDGE packet, PACKET COUNT packet, and DATA packet. Relation between, and ordering of, packets within a message as well as intervals between packets are treated in 6.1.lk, 6.1.10, 6.1.lp, 8.3.lf, and clauses 12 through 20.
5.1 Requirements applicable to all packets
5.1.1 Specifications
(a) In the context of this Standard, a packet shall be a sequence of 17 bits transferred between the M-module and one or more S-modules or from an S-module to the M-module.
(b) Bit <O> of each packet shall contain the packet parity bit.
(c) The parity of each packet shall be odd.
NOTE-The modulo-2 sum of the bits in a packet (bits <16..(k) has to be 1.
(d) Each packet shall be serially transferred, msb first.
(e) Each packet shall be of one of the following types: packet, ACKNOWLEDGE packet, PACKET COUNT packet, DATA packet, or NULL packet.
5.2 HEADER packet requirements
5.2.1 Specifications
(a) The HEADER packet shall consist of the Module Address, Command, Acknowledge request, and parity fields as shown in figure 5-1.
(b) The Module Address field shall be eight bits in length (bits <16..9>) and shall contain an S-module address (3.3.1).
(c) The Command field shall be seven bits in length (bits <8..2>) and contain the 7-bit code determining the command to be executed by the addressed S-module(s).
NOTE--MTM-Bus commands are described in clauses 15 through 20.
(d) The Acknowledge Request field shall be bit <l> and shall be used to request an ACKNOWLEDGE packet to be transmitted by any currently addressed S-module and to indicate that a PACKET COUNT packet will be the next packet transmitted by the M-module (14.1.1b).
5-1
IEEE Std 11 49.5-1 995
(8 bits)
Module Address field
IEEE STANDARD FOR MODULE TEST AND
(1 bit) (1 bit)
Ack parity
bit
(7 bits)
Command field Req bit
msb (16)
(8 bits) (8 bits) (1 bit)
Figure 5-1-HEADER packet format
Module Address field
5.2.2 Description
Module Status field
Precisely one HEADER packet occurs in each MTM-Bus message and is the first packet of the message. From the information in a HEADER packet, each S-module connected to an MTM-Bus can determine if it is addressed, what command is to be executed, and whether the system application controlling the M-module is requesting an ACKNOWLEDGE packet (5.3) from the S-module as part of the message transmission.
5.3 ACKNOWLEDGE packet requirements
5.3.1 Specifications 5.3.1 Specifications
Rules
(a) The ACKNOWLEDGE pa ss, Module Status, and panty bit
Rules
(a) The ACKNOWLEDGE pa all consist of the Module ss, Module Status, and panty bit fields, as shown in figure 5-2.
(b) The Module Address field shall be 8 bits <16..9>) and shall contain the address of the responding S-module.
(c) The Module Status field shall be 8 bits in length (bits <8..1>) and shall contain data residing in the Slave Status register prior to any changes to such data resulting from the receipt of the immediately preceding HEADER packet (9.2).
parity 1 bit
Figure 5-2-ACKNOWLEDGE packet format
5.3.2 Description
An ACKNOWLEDGE packet is transmitted by an S-module upon request and is both a convenient way to recover internal status information from an S-module and is designed to support the Contend for Bus sequence (16.4.1).
5-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
(16 bits)
IEEE Std 1149.5-1995
(1 bit)
5.4 PACKET COUNT packet requirements
5.4.1 Specifications
(a) The PACKET COUNT packet shall consist of a Packet Count field and odd parity bit as shown in figure 5-3.
(b) The Packet Count field shall be 16 bits in length (bits <16..1>) and shall contain either the number of additional packet transfers remaining in the current message or an all-zeros pattern.
(c) An all-zeros pattern in the Packet Count field shall indicate that the current message may contain any number of additional packets.
NOTE-Not knowing the length of a message in advance of receipt is not a problem. Termination of message transmission is controlled by the state of an fsm in the S-module, not by the contents of a packet of within a message (7.1; figure 7-1).
msb Isb (16) (1 1 (0)
PACKET COUNT field
Figure 5-3-PACKET COUNT packet format
5.4.2 Description
If the Acknowledge Request bit is set in the HEADER p of a message, the M-module will transmit a PACKET COUNT packet as the packet immediately following the HEADER packet. A PACKET COUNT packet conveys either the known number of packets still to be transmitted from M-module to S-module in the current message or the fact that the number of such packets has not been, or cannot be, predicted.
The information in a PACKET COUNT packet permits an S-module to determine if a data transfer has occurred as expected. An S-module will detect (9.3.1; figure 9-4; 11.11.1) when an ACKNOWLEDGE packet is requested and the message is terminated early (i.e., when no transfer of a packet takes place after the HEADER packet transfer or when a packet count is received, but does not match the actual number of packets received when message transmission is terminated). An S-module may also use the PACKET COUNT packet information to determine when a message is about to end or to flag an error if a message is too long or too short. Knowing when a message is about to end will be useful in implementing a message integrity check (e.g., CRC value, Hamming code, etc.) at the end of a message.
5-3
IEEE Std 11 49.5-1 995
5.5 DATA packet requirements
5.5.1 Specifications
Rules
IEEE STANDARD FOR MODULE TEST AND
DATA packets shall consist of a Data field containing sixteen (16) bits (bits <16..1>) and one packet parity bit (bit CO>) as shown in figure 5-4.
Binary data 16 or fewer bits long that is to be transmitted in a DATA packet shall be placed in con- tiguous bit positions in the DATA packet such that the least significant bit (lsb) of the binary data is bit <1> of the DATA packet.
NOTE-Which bit of a bit string will be considered the lsb (msb) may be determined by the design@) of the module(s) receiving a DATA packet or the design(s) of applications on thauthose module(s) or the design of other system elements. This Standard mentions msb and lsb in this context to emphasize the necessity of the clear specification of expected bit order in a given module, application, or system. Manufacturers are required to document port-specific data formats (clause 21). Once the msb and lsb of a bit string are determined for a design, the placement of the resulting string in a DATA packet is then determined by the rules in 5.5.1.
If binary data to be transmitted in DATA packets consists of more than 16 bits,
(i) the data bit string: shall be divided (beginning with its least significant 16 bits) into a sequence of 16-bit-long substrings (contiguous in the original data bit string) and, where necessary, a bit string ( S ) containing some number of bits (n, less than 16) representing the n most significant bits of the original data bit string;
(ii) the 16 least significant bits of the binary data shaIl be transmitted in the first transmitted DATA packet, and subsequent 16-bit-long substrings shall be transmitted (in order from least signif- icant position to most significant position with regard to their order in the original data bit string) until all 16-bit-long substrings have been transmitted;
(iii) when all 16-bit-long substrings have been transmitted, then if there is a remaining substring to be transmitted [i.e., S of 5.5.lc(i)], then a final DATA packet shall be transmitted. This final DATA packet shall contain the substring S placctl to fill the n least significant bits of the DATA packet’s Data field.
NOTE--Given a substring that is constructed from an original data bit string to be transmitted over the MTM- Bus, which bit of that substring will be considered the Isb (msb) may be determined by the design(s) of the module(s) receiving the DATA packets or the design(s) of application(s) on that/those module(s) or the design of other system elements. This Standard mentions msb and Isb in this context to emphasize the necessity of the clear specification of expected bit order in a given module, application, or system. Manufacturers are required to document port-specific data formats (clause 21). Once the msb and Isb of a bit string are determined for a design, the placement of the resulting string in a DATA packet is then determined by the rules in 5.5.1.
The contents and format of the DATA packets transmitted as part of a given message shall be as defined for the command code contained in the Command field of the HEADER packet of that message.
NOTE--For example, see 17.1.1 (in particular, note documentation requirements) and the data transfers defined for the commands treated in clause 17.
Recommendations
(e) Any bit positions within a DATApacket that do not contain a bit of a data bit-string being transmitted should be set to a logic: 0.
5-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL
(1 6 bits)
DATA field
IEEE Std 1149.5-1995
(1 bit)
bit Parity
msb (16)
Figure 5-4-DATA packet format
5.6 NULL packet requirements
5.6.1 Specifications
- Rules
(a) A NULL packet shall be a DATA packet consisting of a 16-bit all-zeros field and an odd parity bit as shown in figure 5-5.
NOTE-To maintain odd parity, the parity bit of a NULL packet has to be set to logic one.
msb Isb (1 6) (1) (0)
"0000000000000000"
Figure 5-5-NULL packet format
5.6.2 Description
One use of a NULL packet is its transmission by the M-module during periods when one or more packets of data are being transmitted by an S-module while there is nothing to be transmitted in the reverse direction. The reverse case also will occur. It is important to note that, after transmission of a HEADER packet, during every period of a packet transfer during a singlecast, the MSD and MMD signals are being interpreted (by the M-module and addressed S-module, respectively) as conveying bits of a packet (4.2.la; 6.1.1; 7.1.1). Therefore, failure to transmit a packet is never an option for an S-module addressed by a singlecast message; in such a situation, the transmission of a NULL packet with correct parity is necessary to operation of the MTM-BUS.
5.7 Formatting bit strings of more than 16 bits for transmission in DATA packets
Figure 5-6 provides an illustration demonstrating how a bit string of more than 16 bits is divided so that it can be appropriately transmitted in a series of DATA packets.
5-5
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
DATA packet 2 I 1010101011100011 I o 1 isb
DATA packet 3
Figure 5-6-Formatting a bit string of length greater than 16 for transmission in DATA packets
In figure 5-6, the string to be transferred rice that DATA packets have the lsb in the right-most position in the figure. This means that eac n bits beginning with the Isb has to have its apparent order reversed when formatting the bit nsmittal on the MTM-Bus in a DATA packet. The number of bits in the sample bit string is 11 modulo 16. Therefore, five logic zeros are added as padding in the third data packet; these padding bits are the five high order bits in that packet. In each MTM-Bus packet a parity bit (odd parity) is the Isb of the packet.
5-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
6. MTM-Bus Link Layer: M-module requirements
The Link Layer requirements for the M-module are compact enough to present in this single clause (in con- trast to the Link Layer requirements for S-modules). The order of presentation in this clause is as follows:
- MTM-Bus Master Link Layer Controller requirements - M-module send and receive parity requirements - M-module MPR signal (data transfer control) requirements - M-module response to collision errors on MMD and MCTL signals - M-module interrupt response requirements
6.1 MTM-Bus Master Link Layer Controller (M-Controller) requirements
The operation of the MTM-Bus interface circuit of an M-module with regard to communication over the MTM-Bus is governed by a finite state machine (fsm) described in the present clause. The M-module is COB- trolled by programming of the M-module or a system application that governs the M-module’s response to certain conditions. The fsm described in the present clause does not attempt to deal with states or behavior other than those of the core (required) Link Layer functionality of the M-module.
Before beginning a review of the following specification clause, it will be helpful to the reader to review fig- ures 6-2 and 6-3 and the text in 6.1.2. This figure illustrates the relationships between the edges of the MCLK signal, the state transitions of the M-Controller, and data transmission and reception by the M-module.
6.1.1 Specifications
Rules
(a) The fsm of figure 6-1 (called the MTM-Bus Muster Link h y e r Controller or M-Controller) shall sequence the MTM-Bus message transmission behavior of an M-module.
NOTE-System application hardware or software controlling the M-module exercises control over such things as when the M-module responds to parity errors, interrupts, or assertion by an S-module of the MPR signal. This is accomplished using the three control variables M I , M2, and M3 (table 6-1).
(b) At system power-up of the M-module or following a system-level reset of the M-module, the M- Controller shall be in its POWEBUP2-OO Master Controller state.
(c) For a given Master Controller state, the logic values driven on the MCTL and MMD signals conse- quent to the rising edge of MCLK occurring while the M-Controller is in the given state shall be determined by (respectively) the next to last and last character of the given Master Controller state’s name. When such a character is an “X,” the value to be driven shall be the value of the data bit being transmitted (6.1.19.
NOTELNames of Master Controller states (with the exception of the WAIT-00 Master Controller state) have been chosen such that the alphabetic characters before the under bar indicate the Slave Controller state that will result in an addressed S-module when that S-module latches, registers, and has access to the values driven on MCTL and MMD (figures 6-2; 6-3; and 7-1, including accompanying notes; and 7.1.1).
(d) Precisely one state transition of the M-Controller shall occur in each cycle of the MCLK signal.
NOTE-The M-module begins to drive “new” values of MCTL and MMD consequent to each rising edge of the MCLK signal (4.4.le). Consequent to the next falling edge (4.4.10 of the MCLK signal, the M-module latches the value on its MSD signal input. Relation of M-module operations and changes of state of the M- Controller to edges of the MCLK signal are presented in figures 6-2 and 6-3 with respect to a model of M- module internals depicted in figure 6-2. The internals of an M-module are unlikely to be observable. This Stan- dard specifies external behavior of an M-module.
6-1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
m, X, id3
0 POWERUP2-00 M1, X, X
m, X, M3
This set of arcs, too small to label conveniently, represent transitions made in response to MI, X, X. -
Next state of the M-Controller is determined by the values of 3 (three) variables:
MI-set if a collision is detected on MMD or MCTL. M2-set if and only/f(l) an S-module has asserted the MPR signal (figure 6-2) and the M-module is programmed to respond to MPR by delaying further transmission or (2) there is some system reason or M-module internal reason for delaying further transmission. M 3 s e t if next transition is (1) to EOM-00 or (2) to IDLE-00 from some state other than EOM-00) and cleared if next transition is to XFER16-IX.
The conditions under which MI and M3are set are intentionally incompletely specified. In the case of M3, the only advantage to be gained may be convenience of design or speed of operation. In the case of M7, the designer of an M-module is provided a mechanism by which conditions other than collisions on MCTL or MMD may be allowed to cause immediate cessation of normal message transmission.
An ordered triple or Boolean combination of ordered triples of these values (written in the order MI, M2, M3) is placed next to each arc and provides the conditions under which the state transition represented by that arc will occur. The value "X" in a triple indicates a "don't care" condition.
State transitions occur between each falling edge of the MCLK signal and the immediately subsequent rising edge of the MCLK signal.
Master Controller states XFERl2-lX to XFER3-1X are not shown, but would be drawn with connecting state transition arcs labeled, directed, and terminated identically to those shown for XFERl3-1X.
?dT, M2, X
M1, X, X
NOTE-Master Controller state names have been selected such that each ends with the pair of logic values to be driven on MCTL and MMD in a given Master Controller state.
Figure 6-1-MTM-Bus Master Link Layer Controller state diagram
6-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL lttt
Std 1149.5-1995
(e) An M-module shall respond to values driven on the MSD or MPR signals by behaving in a manner consistent with figure 6-1 and the model of figure 6-2.
NOTE-Figure 6-2 depicts an implementation that would achieve the desired behavior4specially with regard to timing. See note under 6.1.ld. Output signal behavior is specified by 6.1.1~.
(f.) An M-module shall transmit one and only one data bit in each of the seventeen M-transfer states.
NOTE-The M-transfer states are those Master Controller states the names of which begin with the characters “XFElR.”
(g) The seventeen data bits transmitted in one seventeen state sequence through the M-transfer states shall be the seventeen bits of a single packet.
(h) The M-module shall not transmit a bit of a message in any Master Controller state other than the M-transfer states.
(i) The value of the MMD signal driven by the M-module in any of the seventeen M-transfer states shall be the data bit to be transmitted in that state,
NOTFLThe bits of a packet are transferred msb first (5.1.1d).
(i) The M-module shall read the value on the MSD signal during each seventeen state sequence through the M-Controller beginning with the XFER14-lX Master Controller state and shall interpret the sev- enteen bits read as comprising a single packet transmitted by an S-module (or in the case of the exe- cution of the Contend for Bus command (16.4.1), as a single packet or the logical-OR of single packets transmitted by one or more S-modules).
NOTES
1-All MTM-Bus signals are latched on the falling edge of the MCLK signal (4.4.10.
2-The last bit of a packet received by the M-module may be received in the M-Controller’s XFER16JX Master Controller state if the M-Controllcr rcmains in its PAUSE-01 Master Controller state for only one cycle of the MCLK signal. Otherwise, the lasl bit will be receivcd while the M-Controller is in its PAUSE-01 Master Controller state.
3-The situation of the M-module receiving the logical-OR of two or more complete packets with good parity will only occur if two S-modules operate as though they have a common address (e.g., due to a system config- uration error) and are transmitting identical packets or two or more S-modules are responding to the amnesia address [3.3.ld(ii)] and transmitting identical packets.
(k) An M-module shall be capable of supporting message transfer in which the M-Controller remains in the PAUSE-01 Master Controller state for no less than four (4) cycles of the MCLK signal after the transfer of every packet.
NOTE-Rule 6.1.la (figure 6-1) requires that the M-Controller will be in the PAUSE-01 Master Controller state for at least one cycle of the MCLK signal following the transmission of every packet of a message and indicates conditions under which the M-Controller may remain in its PAUSE-01 Master Controller state for more than one cycle of the MCLK signal. Clause 4.3.1~ recommends that an S-module be designed with the ability to support the MPR signal. The use of MPR is an appropriate way in which to reduce interrupt latency while offering some improvement in throughput over that which would be obtained by having the M-Control- ler remain in its PAUSE-01 Master Controller state for a fixed number of cycles (>1) of the MCLK signal. Also, see 6.1.10.
(1) To signal the termination of transmission of the current message, the M-Controller shall be placed in the EOM-00 Master Controller state.
6-3
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(m) To signal that no message is currently being transmitted, the M-Controller shall be placed in or remain in the IDLE-00 Master Controller state.
(n) The manufacturer of an M-module shall document any inputs to the state variables MI and M3 (table 6- 1) that are not explicit in figure 6-1.
NOTE-Inputs to the state variable M2 (figure 6-1) are completely specified.
(0) The M-Controller should remain in its PAUSE-01 Master Controller state for at least four (4) con- secutive cycles of the MCLK signal following the transmission of
(i) every HEADER packet;
(ii) every message-terminating packet.
NOTES
1-Following 6.1.1o(i) will allow time for S-modules with software-based implementations to detect that they are addressed and to assert MPR if necessary before the M-module begins to transmit the packet following a HEADER packet.
2- Likewise, adopting 6.1.1o(ii) will allow an addressed S-module to do such things as detect “interpacket errors”-Packet Count (1 1.11. l), Port Transfer (1 1.8.1), and Parity (1 1.5.1) errors-and do requisite error pro- cessing for, and generate appropriate interrupts due to, these errors. It may be of special value in a case in which an uniquely addressed S-module has neither of the interrupt pmgramming bits (PIE, IIE) in that S-module’s Slave Status register set (9.3.1: 10.1.1: table 10-1). In this case, the S-module is only be able to generate an interrupt during its S-Conlrollcr’s PAUSE Slave Controller state; and allowing some extra time for processing before termination of a message may be important.
Permissions
The M-Controller may remain in its PAUS of the MCLK signal where n is greater than or equal t
NOTES
ntroller state for any number, n, of cycles
1-The actual number of such cycles will be controlled by a systcm application or the M-module. This control is outside the scope of this Standard.
2-The actual number of such cycles can be influenced by an S-module’s asserting of the MPR signal and will be controlled by a system application or the M-module. This control is outside the scope of this Standard.
The number of cycles of the MCLK signal during which the M-Controller may remain in its IDLE-00 Master Controller state may exceed the number of cycles required by the above rules.
NOTE-The actual number of such cycles will be controlled by a system application or the M-module. This control is outside the scope of this Standard.
6.1.2 Description
The M-module requires control for purposes of sequencing through the packet transmission process and for responding to S-module interrupts and certain error conditions. This control is supplied by the M-Controller and by direction of M-module programming or system applications.
Names of Master Controller states are composed of two portions: an alphabetic character string prior to an underbar (prefix) and an alphanumeric string of two characters following the underbar (suffix). With the
6-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
exception of the WAIT-00 Master Controller state, the prefix names the Slave Controller state (7.1; figure 7-1) to which an addressed S-module will be directed by the values of MCTL and MMD that are to be driven in the given Master Controller state. The suffix provides those values in the order <MCTL, MMD>.
1 MPR MPR-LTCH I M-module i ~2 : IS-DATA-BIT
! Control I
MSD -
MCLK
I MSD-LTCH
NOTES
l-Figure 6-2 illustrates a model of the operation of M-module input latching and registration. A "new" value of MSD is driv- en by an S-module on the rising edge of the MCLK signal. On the immediately subsequent falling edge of the MCLK signal, this value is latched and becomes the value of the signal labeled MSD-LTCH. One half cycle of the MCLK signal later, the value is registered and becomes the value of the signal labeled MSD-REG. One full cycle of the MCLK signal after the new value was originally driven, the registered value may be detected as an interrupt or be accepted for processing as incoming data. Two full cycles of the MCLK signal have passed since the S-module originally drove the "new" value onto the MTM- Bus. The MTM-Bus specifies that the MSD signal is used to convey both data and interrupt signals from S-modules. This model includes a signal from the M-Controller (IS-DATA-BIT) that controls selection between MSD-LTCH (connected di- rectly to M-module Interrupt Processing circuitry when IS-DATA-BIT has the value logic 0 [6.5.la]) and MSD-REG (con- nected directly to M-module data handling circuitry when IS-DATA-BIT has the value logic 1 [6.5.laJ) according to whether the incoming bit is to be examined as a possible interrupt or interpreted as data. This selection is determined by Master Controller state and interrupt control programming (figure 6-1; 6.5.la; clause 11). Control of the M1, M2, and M3 state vari- able signals is treated abstractly. When M-module programming permits response to a pause request, MPR-LTCH has to affect M2 without intervening sequential circuitry. To simplify the illustration, the MCLK signal is not connected to the reg- isters receiving input data (M-module Input Data); and output data controls are omitted (although to reassume packet trans- mission after MPR is released requires that M2 be feeding some sort of gating in the Output Data Control block). This model is an arbitrary depiction of M-module internals for purposes of explanation. The Master Controller states and state transi- tions of the M-Controller are unlikely to be directly obselvable in an M-module. This Standard specifies the obsewab/e be- haviorof an M-module. 2-It is a consequence of the combined figures 6-1 and 6-2 that an S-module wishing to prevent transmission of a following packet has to have asserted the MPR signal three cycles of the MCLK signal prior to the point at which its S-Controller would be expected to enter its XFER16 Slave Controller state (figure 7-1). For example, if an M-module is operating in a manner such that its M-Controller remains in its PAUSE-01 Master Controller state for only one cycle of the MCLK signal between transmission of packets, the S-module has to (8.3) assert MPR upon entering its S-Controller's XFER1 Slave Con- troller state (figure 7-1) in order to be able to delay transmission of a subsequent packet.
Figure 6-2-A model of M-module internals related to (1) M-module input value latching, (2) M-module registration of a latched MSD signal value, (3) the MCLK signal, and
(4) state transitions of the M-module's M-Controller
6-5
IEEE Std 114951995 IEEE STANDARD FOR MODULE TEST AND
a
b t "'1
b' t b"
i NOTE-The M-module begins to drive "new" values of MCTL and MMD consequent to the rising edge of the MCLK signal marked a. Consequent to the falling edge marked b, the M-module latches the value on its MSD signal input. This latched value is registered in the M-module at the rising edge marked a' at the same time that the "second" set of MCTL/MMD values is driven by the M-module. At the falling edge marked b', the %cond" MSD input value is latched by the M-module (figure 6- 2). The change of state of the S-module's S-Controller that depends on the values driven by the M-module at a occurs on the rising edge marked a". Also at time a", (1) the output(s) thatthe S-module is to generate during the newslave Controller state (if any) idare driven on the MSD (and MPR) signal(s) (i.e., the "third" set of values to be input to the M-module is driven), (2) the "second" MSD value driven by the S-module is registered by the M-module (figure 6-2), (3) the M-module drives the 'Third"
driven onto the MTM-Bus. On the other hand, it is not modelde at processing of a bit of S-module-originated data
state are driven onto the MTM-Bus roughly s ntry into that Master Controller state. The
Figure 6-3-Timing relatio 1) M-module input value latching, 2 gistration of a latched MSD value,
Figures 6-2 to 6-5 relate the edges of the ller state transitions and the driving of values on MCTL and MMD and the latchin ddition, figure 7-4 illustrates the rela- tionship in time between an M-module ente er state and an addressed S-module's state transition resulting from the values of the MCTL and Mh4D signals driven in that Master Controller state. The sequence is associated with edges of the MCLK signal as follows:
Suppose the current Master Controller state is xFER14-1X and that the transition into that state has just occurred consequent to a rising edge of the signal on MCLK. Let the time be at a in figure 6-3. The M-module is driving a logic 1 on the MCTL signal and a data bit value on the MMD signal (the third bit of a packet).
At the immediately subsequent falling edge of the signal on MCLK (b in figure 6-3), the values driven by the M-module are latched by the S-module receivers.
At the first rising edge of the MCLK signal after a (i.e., a'), receiving S-modules will register the MCTL and MMD values driven at a by the M-module.
At the edge marked a", two cycles of the MCLK signal after the M-module drove the set of values describe in the first item of this list, that MCTL/MMD signal value pair will cause an addressed S- module's S-Controller to enter its xFER14 Slave Controller state (7.1.1 ; figures 7-3 and 7-4).
MAINTENANCE BUS (MTM-BUS) PROTOCOL
MCLK 1 a
IEEE Std 1149.5-1995
1 a” 1 M.C.state PAUSE-01 I XFERl6-1X XFERl5-1X XFERl4-1X XFERl3-1X
I MCTL
S. C. state XFERl I XFERO PAUSE XFER16 XFER15
NOTE-As an example, a period of time is selected that coincides with the beginning of the transmission of a packet otbef than the first or second packet of a message; moreover, it is assumed that the M-module is spending only one cycle of the MCLK signal with the M-Controller in its PAUSE-01 Master Controller state. As in the model of figures 6-2 and 6-3, we as- sume that change of Master Controller state occurs simultaneously with the change of values on the MCTL and MMD sig- nals. We have arbifmQshown state changes in the M-module and the S-module occurring simultaneously. Of course, both are black boxes, and the time of the state change is unlikely to be known to a user. Only the output behavior of the black box is testable for conformance to the Standard. The illustration depicts the relationship of Master Controller states to Slave Controller states (7.1.1). Other than in the case of a HEADER packet, the M-module and the S-module transmit packets to each other in pairs. The packet that is transmitted by the M-module beginning with the rising edge of the MCLK signal at a is paired with the packet that is transmitted by the S-module beginning with the rising edge of the MCLK signal at a”. At a, the MCTL signal is asserted indicating the beginning of transmission of a packet.
Figure 6-&Relationship of Master Controller states, Slave Controller states, packet transmission, and the MCLK signal
-
PACKET COUNT packet bits - HEADERiacket bits I - MMD
1 ACKNOWLEDGE packet bits1 - MSD
2 cycles of the MCLK signal +a k
NOTE-During the transfer of a HEADER packet, the Slave Data (MSD) signal is released as no S-module yet knows to participate in the message-none are addressed. The rising edge of the MCLK signal at time a occurs (in the model of figures 6-2 and 6-3) when the M-Controller enters its XFER16-1X Master Controller state. The rising edge of the MCLK signal at time a” occurs when the M-Controller enters its XFERl4-1X Master Controller state. The Master Controller states and state transitions of the M-Controller are unlikely to be directly observable in an M-module. This Standard specifies the obsewab/e bebaviorof an M-module.
Figure 6-5-HEADER packet and PACKET COUNT packet transfer
6-7
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
The names and meanings of the three state variables controlling transitions of the M-Controller are provided in the large note of figure 6-1 and are used in that figure to encode state transition conditions. Transition through the M-transfer states is a simple flow with divergence caused only by the setting of the state variable MI or by terminating a message after complete transmission of a packet by simultaneously clearing MI and setting M3 (to cause transition between the PAUSE-01 and EOM-00 Master Controller states). Note that MI has to be set as a result of detection of collision on the MCTZ or the MMD signal (figure 6-1). A sum- mary of the use of the three state transition variables is provided in table 6-1.
Table 6-1-Synopsis of use of state transition variables of the M-Controller
May be used to cause immediate halt of message transmission under control of M-module or sys-
Mandated to be cleared when the next transition is (a) to XFERlhlX or (b) to POWERUP2-00 from POWERUP2-00.
Implementations of responses to operating conditions that may cause the M-Controller’s transition to its WAIT-00 Master Controller state are not addressed in detail by this Standard.
Among the variable-affecting conditions controlling flow in the fsm of figure 6-1, detection of a collision and ability to respond to panty errors and the MPR and MSD signals are required by this Standard. M3 is potentially controlled by a system-level application or by M-module programming (4.2.lb; 4.2.1~; 4.2. Id; 6.2.lb; 6.2.1~; 6.3.1; 6.5.1; 8.2.1; 8.3.1).
It is recommended (6.1.10) that an M-module or the appropriate system application controlling an M-module hold the module’s M-Controller in the PAUSE-01 Master Controller state for at least four cycles of the MCLK signal following transmission of the first and last packets of a message. Clause 6.1.1 k requires that this delay be possible in every M-module after evely packet of a message.
If this is not done as a matter of course, the MPR signal of an addressed S-module can help avoid data over- flow and interrupt latency problems (6.3; 7.1.2). If an addressed S-module does not include implementation of the MPR signal, then the timing of some events may become tight and operating speed of a particular MTM-Bus implementation may have to be held down as a result. Whether or not MPR is implemented on the S-modules of a given system, it is valuable to have the M-Controller remain in its PAUSE-01 Master Controller state for at least four cycles of the MCLK signal following transmission of an HEADER packet. This would provide time for a software-controlled S-module implementation that needed to request a PAUSE after an HEADER packet to
- check parity of the HEADER packet; - detect that it is addressed by the HEADER packet;
- assert the MPR signal sufficiently early so that it is possible for it to be detected by the M-module before transmission of the next packet begins.
6-8
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
6.2 M-module send and receive parity requirements
6.2.1 Specifications
Rules
(a) The M-module shall have the ability to be directed to transmit either HEADER or DATA packets having bad parity.
NOTE-This capability allows test of an S-module ability to detect parity errors.
(b) The M-module shall have the ability to detect bad parity in a packet received from an S-module.
(c) When a packet is not required from an S-module-during a multicast or broadcast message transfer or during the transfer of an HEADER packet, the M-module shall not record a received parity error.
(d) The M-module shall always transmit a packet with valid parity except during testing of the parity detection capability of S-modules (6.2.la).
Permissions
(e) The manufacturer of an M-module may implement a means of programming the M-module either to halt transmission of the current message to take an appropriate action to respond to the detection of bad parity or to continue transmission of the current message (i.e., to ignore bad parity).
NOTES
1 T h i s Standard requires that an M-module be able to detect bad parity on a received packet (6.2.lb); however, permission is given to continue message transmission even if such a condition is detected. Implementation of this permission would affect the value assigned to MI (table 6-1) when a parity error is detected. The M-Con- troller has to remain in its PAUSE-01 Master Controllcr state long enough for the parity checking to be com- pleted and the value of MI to assigned. Setting MI will cause transmission to terminate. Clearing M1 allows transmission to continue when M2 and M3 are assigned appropriate values. The details of M-module response to the detection of bad parity on a received packet are b
2-If 6.2.le is implemented, 22.1 .lb requires that the means of programming involved be fully documented by the manufacturer of the M-module.
nd the scope of the Standard.
6.2.2 Description
The M-module communicates to the S-modules through HEADER, PACKET COUNT, and DATA packets (clause 5). Special requirements concerning the transfer of these packets are described here, in 8.3, and in clauses 12 through 14.
The M-module has to have the ability to send bad parity on DATA packets to facilitate the testing of the S- module’s parity checking circuitry. For example, the M-module might perform such a test as part of a power- on self-test sequence that tests each part of the interface thoroughly prior to beginning normal bus opera- tions. The M-module may also send bad parity on HEADER packets to verify that S-modules ignore mes- sages that begin with a HEADER packet that contains a parity error (8.1.la and clause 11).
When the M-module transmits a HEADER packet as shown in figure 6-5, the value on the Slave Data (MSD) signal will remain a logic 0 as no S-module can yet determine if it is addressed and should partici- pate in the message. Accordingly, the M-module’s low-level bus interface circuitry has to be designed such that it doesn’t provide a “blind” parity check at the end of every packet transfer period. This same condition occurs throughout Multicast and Broadcast messages when S-modules are not permitted to respond.
6-9
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
When the M-module detects bad parity in an S-moduletransmitted packet, the M-module may either
- terminate the current message (if the packet with bad parity was not the last to be transferred in the message) by causing the M-Controller to go through the necessary transitions to enter its IDLE-00 Master Controller state;
- continue transfer of any packets that may remain to be transferred in the current message.
In either case, the application controlling the M-module may cause some tests to be applied to try to diag- nose the cause of the bad parity (e.g., by using a test command such as the Data Echo Test command [ 16.11.11 or by resetting suspect S-modules using the Reset Slave Status command [ 16.3.13).
6.2.ld requires that the M-module always transmits valid parity during every packet transfer (except when testing the S-module's parity checking logic). This requirement will allow for an S-module interface design that can blindly check parity for every packet transfer in every message in which it participates.
6.3 M-module MPR signal (data transfer control) requirements
6.3.1 Specifications
Rules
(a) An M-module shall be designed to be
(i) to respond to the MPR signal, i.e., maintain behavior as though (with regard to the model of figure 6-2) M2 were connectcd to MPR-LTCH without intervening circuitry;
(ii) to ignore the MPR signal and attempt a message transfer even though that signal may be asserted, i.e., set the stat2 varinhlc M2 (figure 6-1) equal to logic zero.
NOTE-While this rule appeals to the model of figure 6-2, this is only a mechanism allowing this Standard to spec- ify behavior of an M-module. This Standard specifies the observable behavior of an M-module.
Recommendations
(b) The M-module should include a programmable means to be used to define a limit on the time that the M-Controller continuously remains in its PAUSE-01 Master Controller state. If the programmed limit is exceeded (e.g., an S-module asserts the MPR signal too long according to relevant system design specifications), programmed permission for the M-module to respond to the assertion of MPR [6.3.la(i)] should be overridden, i.e., the state variable M2 set equal to logic zero.
6.3.2 Description
An M-module has to have the ability to respond to the MPR signal (4.2.1~). However, there may be cases in which it is prudent to ignore assertion of this signal, and this Standard requires that the M-module have the flexibility to be programmed to do so. If an error in an S-module causes MPR to be asserted constantly, then continued, degraded operation of the MTM-Bus may be possible if the M-module is programmed (by the controlling application) to ignore the MPR signal. Response to the MPR signal is controlled by the value of the M2 state variable (table 6-1).
If an error occurs such that the MPR signal remains asserted once a normally functional S-module would have released it, the M-module might wait indefinitely for the MPR signal to be released if the situation were not foreseen. Accordingly, it is recommended that the M-module include a timing function that will cause further diagnostic action to occur once the MPR signal has been asserted for some system-dependent time
6-10
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
period. This timing function might operate off of a clock other than MCLK so that a fault on MCLK will not prevent notification of the system that a failure has occurred on the MTh4-Bus.
6.4 M-module response to collision errors on MMD and MCTL signals
If the M-module detects a collision on the MMD or MCTL signals, it will (in accord with 6.1.la and figure 6-1) release the MCTL, and MMD signals for at least two full cycles of the MCLK signal.
When this occurs, the M-Controller will go to its WAIT30 Master Controller state. The current message transfer is terminated. Further action to be taken by an M-module or system application when this error occurs is beyond the scope of this Standard.
Collision on the MMD or MCTL signals can indicate a short between them, the presence of a driver fault, or (perhaps) that a Master-capable S-module has somehow begun to act as an M-module while the previous M-module is still attempting to control the MTM-Bus. In any such case, the MTM-Bus implementation is not operating as designed and corrective action is required.
6.5 M-module interrupt response requirements
S-module interrupt generation is treated in clause 10. S-module error handling is treated in clause 11. A response to an interrupt usually involves taking action to discover the cause of the interrupt and, if possible, to eliminate the cause or render it minimally threatening to MTM-Bus operation.
6.5.1 Specifications
(a) To detect interrupt requests from an S-module, the M-module shall be designed so that (following the model of figure 6-2 and accompanying notes) the MSD-LTCH signal shall be directly connected to the M-module interrupt processing circuitry (i.e., the value of IS-DATA-BIT shall be logic 0) during and only during the following Master Controller states:
(i) the IDLE-00 Master Controller state;
(ii) the XFERlS-lX, XFER16_1X, and PAUSE-01 Master Controller states ifno packet bit from the S-module is to be read in the state in question in the present cycle of the MCLK signal.
NOTES
l a n c e S-module transmission of a given packet is completed, an S-module permitted to signal an interrupt in its S-Controller’s PAUSE Slave Controller state may begin to do so by assertion of the MSD signal (10.1.1). Similarly, once a message is completed, an S-module permitted to interrupt in its S-Controller’s EOM and IDLE Slave Controller states may do so by assertion of the MSD signal.
2-If an M-module is operating in such a manner that its M-Controller remains in its PAUSE-01 Master Con- troller state for only a single cycle of the MCLK signal between packets of a message, the S-module may signal an interrupt (if programmed to do so) in its PAUSE Slave Controller state, and the M-module will detect it in the M-Controller’s XFERlS-1X Master Controller state-with a new packet transmission already under way, Similarly, if two cycles of the MCLK signal occur between packets of a message, the M-module will detect interrupts in its XFER16-1X and XFER15-1X Master Controller states-again, in this case, new packet trans- mission has been initiated before an interrupt can be detected. To allow for detecting an interrupt and responding to it without beginning to transmit another packet requires that the M-module operate in such a way as to have its M-Controller remaining in its PAUSE-01 Master Controller state for at least three cycles of the MCLK signal.
6-11
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(b) The manufacturer of an M-module shall implement a means of programming the M-module (fol- lowing the model of figure 6-2) to function in any of the following ways:
(i) tu respond tu assertion of the MSD-LTCH signal (i.e., initiate servicing of a signaled interrupt) during Master Controller states listed in 6.5.la;
(ii) to detennine the timing and nature of the response to an interrupt;
(iii) tu ignore assertion of the MSD-LTCH signal during Master Controller states listed in 6.5.la.
NOTES
1-This Standard requires that an M-module be able to detect the assertion of the MSD signal when it is used as an interrupt signal; however, the M-module also has to be able to continue message transmission even if it detects an interrupt. Details of response to the assertion of the MSD signal as a means of signaling an interrupt are beyond the scope of the Standard.
2-22.1.lb requires that the means of programming involved in an implementation of 6.5.lb be fully docu- mented by the manufacturer of the M-module.
(c) The manufacturer of an M-module shall document the maximum duration(s) of responses to detected assertion of the MSD signal in te
NOTEbIt is not only important to be able The designer of a system using the MTM-Bus, has to know how long the response may be expected to take.
les of the MCLK signal.
modulc to respond or not respond to an interrupt.
Permissions
(d) The programmability required in 6.5. Ib may be expanded so that response to the MSD-LTCH signal may be ignored for none of, all of, or some subset of the states specified in 6.5.la.
NOTE-22.1.la requires the mii i i i ra
accord with 6.5.ld. to document all capabilities implemented in
6.5.2 Description
Clause 10 contains the specifications governing the assertion of the MSD signal by an S-module for the pur- poses of signaling an interrupt. This Standard only specifies s when an M-module has to observe the MSD signal for the purpose of detecting an intempt. It i d the scope of this Standard to specify M-module or system responses to interrupts other than those error responses specified in clause 11.
6-12
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
7. MTM-Bus Link Layer: S-module requirements-MTM-Bus Slave Link Layer Controller
7.1 MTM-Bus Slave Link Layer Controller requirements
The operation of the MTM-Bus interface circuit of an S-module with regard to communication over the MTM-Bus is governed by a finite state machine (fsm) described in the present clause.
Before beginning a review of the following specification clause, it will be helpful to the reader to review fig- ures 7-3 and 7-4 and the text associated with them in 7.1.2. These figures illustrate one model of the relation of edges of the MCLK signal, the state transitions of the S-controller, and data transmission and reception by the S-module. This is only one model and not a required or recommended implementation. The states and state transitions of the MTM-Bus Slave Link Layer Controller are unlikely to be directly observable in an M-module. This Standard specifies the observable behavior of an S-module.
7.1.1 Specifications
The fsm of figure 7-1 (called the MTM-Bus Slave Link Layer Controller or S-Controller) shall sequence the MTM-Bus message transmission behavior of an S-module.
NOTE-The S-Controller of an unaddressed S-module makes all state transitions just as does the S-Controller of an addressed S-module.
Precisely one state transition of the S-Controller shall occur in each cycle of the MCLK signal.
An S-module shall respond to values driven on the MMD and MCTL signals by behaving in a manner consistent with figure 7-1 and the model of figure 7-3.
NOTE-Figure 7-3 depicts a model of S-module internals that would satisfy this requirement. The model of figure 7-3 is not intended to represent a desired or recommended implementation of S-module internal cir- cuitry. That figure is used only to specify the external behavior of an S-module--especially with regard to timing.
An S-module shall interpret signal values on MMD as data when and only when such an MMD signal value (having been latched by the S-module simultaneously with the latching of a logic one on the MCTL signal) causes entry into one of the seventeen S-transfer states.
NOTE-The S-transfer states are those Slave Controller states the names of which begin with the characters “XFER.” Since data is latched at the MCTL and MMD inputs only once in each Slave Controller state, one and only one bit of data will be available to S-module internals in each S-transfer state.
The seventeen data bits recorded in one seventeen-state sequence through the S-transfer states shall be interpreted by an S-module as the seventeen bits of a single packet transmitted by the M-module.
NOTE--It is a convenient convention to speak of the data bit of the MMDMCTL signal pair ultimately caus- ing entry into an S-transfer state as having been “recorded” in that state. Since the MCTL and MMD signals together convey control information, the values latched on a falling edge of the MCLK signal ultimately cause both a state transition and (in the case that the transition is one terminating in a S-transfer state) transmission of the bit of data transferred in the new state-according to the timing described in figure 7-4 and the accom- panying note. Another way of looking at this is that the MCTL signal always conveys control information while the MMD signal conveys control information when the value of the MCTL signal is a logic 0, but con- veys data when the value of the MCTL signal is a logic 1.
7- 1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(f) An uniquely addressed S-module or one participating in a Contend for Bus sequence (16.4.1) shall transmit one and only one data bit during each S-transfer state.
NOTE-Beginning S-module packet transfer in the XFERl6 Slave Controller state provides a delay of 2 cycles of the MCLK signal between initiation of M-module packet transmission and that of S-module packet transmission (figure 7-4 and accompanying note).
(g) The seventeen data bits transmitted in a single pass through the seventeen S-transfer states cited in 7.1.lf shall be the bits of a single packet. An S-module shall not transmit a bit of a message in any Slave Controller state other than those cited in 7.1.lf.
NOTE-The bits of a packet are transmitted msb first (5.1.1d).
(h) An S-module that was addressed immediately prior to its S-Controller’s entry into its EOM Slave Controller state shall still be addressed when its S-Controller is in the EOM Slave Controller state.
NOTES
1-Since, once the M-module transmission of DATApackets of a given message is completed, it is the respon- sibility of the system-level application controlling the M-module to direct the M-module to send NULL packets while DATApackets are still expected back from anuniquely addressed S-module, the issue of S-module packet transmissions beyond the end of M-module packet transmissions does not arise.
2 S i n c e a State Sequence Error may be recorded by a transition of an S-Controller from its EOM Slave Con- troller state to its ERROR Slave Controller state, the only manner in which the Occurrence of the error can be conveyed to the M-module is if the relevant S-module is addressed when the error is detected (1 1.6.1).
(i) An S-module shall interpret the fact that its S-Controller is in its IDLE Slave Controller state as the indicator that
(i) no message is being transmitted;
(ii) the given module is not addressed.
NOTE-When an S-module is not addressed and its SController is in its IDLE Slave Controller state, that S- module cannot signal an intempt unless the IIE bit is set in that S-module’s Slave Status register (9.2.1; 10.1.1).
(j) When an S-module completes its power-up sequence, the S-Controller of the S-module shall be placed in its POWERUP1 Slave Controller state.
NOTE-7.1. lj defines the initialization of an S-module’s S-Controller.
NOTE-State transitions occur once per MCLK signal cycle, affect S-module outputs on the rising edge in that cycle, and are determined by MCTL and MMD signal values driven by the M-module two MCLK signal cycles before that ris- ing edge (figure 7-4).
7.1.2 Description
The transmission of data on the MTM-Bus is controlled by the M-module’s asserting and releasing the Con- trol (MCTL) and Master Data (MMD) signals. The registered values of these two control signals (as in the model of figure 7-3) controls the S-Controller state transitions as shown in figure 7-1. S-Controller state transitions may be modeled to occur on the rising edge of the MCLK signal consistent with 4.4.le, 7.1.lb, and 7.1. IC (figures 7-3 and 7-4).
From any Slave Controller state in the state diagram of figure 7-1, the IDLE Slave Controller state can be reached simply by holding both MCTL and MMD at logic 0 for two consecutive cycles of the MCLK signal. This fact is useful for synchronizing the M-module with S-modules.
7-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL I€€€
Std 11 49.5-1 995
01 or 1X
\ 00
The set of arcs terminating at the ERROR Slave Controller state represent transitions called State Sequence Errors.
In response to a State Sequence Error, the SSE bit in the S-module’s Bus Error register will be set only if the S-module is addressed (table 9.4; 11.6.1). ~
Next State is determined by the values of the MCTL-REG, MMD-REG signals (figure 7-3). A pair of these values, expressed as an ordered pair <MCTL-REG,MMD-REG>, is placed next to each arc and provides the conditions under which the state transition represented by that arc will occur.
State transitions occur between each falling edge of the MCLK signal and the immediately following rising edge of that signal.
Slave Controller states XFER12 to XFERB are not shown, but would be drawn with connecting state transition arcs labeled, directed, and terminated.
ox
ox e, XFER15
ox ‘7; XFER14
XFER13
7 La XFER2
I
I 01 I
01 1 1
1x
I
I O0 L * l 1X or 01
Figure 7-1-MTM-Bus Slave Link Layer Controller state diagram
7-3
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
PO WERUPI and PO WERUP2 Slave Controller states-An S-module’s S-Controller is expected to enter the POWERUPl Slave Controller state as a result of the S-module’s power-up sequence (7.1.1j). One sce- nario for system start-up is that the M-module might be powered up first and remain in its POWERUP-00 Master Controller state until all S-modules connected to the MTM-Bus have completed their power-up sequences. Two cycles of the MCLK signal after the last S-module’s S-Controller enters its POWERUPl Slave Controller state, the S-Controllers of all S-module’s on the MTM-Bus will be in the IDLE Slave Con- troller state. The processing of test messages or other start up procedures utilizing MTM-Bus functionality can then proceed.
EOM and IDLE Slave Controller states -Entry of the S-Controller of a formerly addressed S-module into its IDLE Slave Controller state marks the end of a message for the given S-module; the S-module ceases to be addressed. When the S-Controller is in its IDLE Slave Controller state this is an indication that no mes- sage is being transferred between the M-module and the S-modules and that no S-module is addressed. Two Slave Controller state transitions are required between MTM-Bus messages (i.e., the MTM-Bus Link Layer protocol requires a minimum of two cycles of the MCLK signal while MCTL and MMD are both released). Explicitly requiring two Slave Controller states between message transfers (EOM and IDLE) is intended to address a problem that might occur [item b)] if there were a glitch on MMD while it was intended to main- tain the S-Controller in its PAUSE Slave Controller state. Note that for the S-Controller to remain in its PAUSE Slave Controller state, the logic values on MCTL and MMD have to be 0 and 1, respectively. Con- sider the cases of single bit glitches:
a) If the glitch is on MCTL, the transition cycle of the MCLK signal module). This will lead to 1) immediately (if MCTL 2) if a new packet transfer nal following the glitch, at the end
of the transfer of that (In the latter case, note h a t 111c M-rriotlule will send one last bit of data after the S-module’s S-Con- troller has left its XFElIO Slavc C‘onlrollcr stilk.)
lave Controller state will occur at least one srnission of the next packet from the M-
b) If the glitch is on MhII), 1hc impropcr stiltc transition will be to the EOM Slave Controller state. Since we have assumed I l l i l l tlic glicch lasts only one cycle of the MCLK signal, the next pair of logic values received by the S-module on MCTL and MMD have to be either 1) “1X’ (start of next packet transmission) or 2) “01” (S-Controller signalled to remain in its PAUSE Slave Controller state). In either case, a State Sequence Error will be detected.
If condition b(i) were to occur and there wcre no EOM Slave Controller state, then the S-module’s interface circuitry would interpret the following packet transmission as the transmission of a HEADER packet. Note that the EOM Slave Controller state is only intended to protect against single glitch errors that might cause an early exit from the PAUSE Slave Controller state.
An S-module may signal an interrupt to the M-module during the EOM and IDLE Slave Controller state consistent with clause 10.
S-transfer states (XFER16 through XFERO Slave Controller states) -The S-transfer states are those Slave Controller states in which an M-module transmitted packet is recorded by one or more S-modules. Packets are always transferred msb (bit 16) first (5.1.1d). The msb of an M-module transmitted packet is available to S-module internals (i.e., is recorded) during the XFER16 Slave Controller state. The parity bit (the lsb) of a packet transmitted from the M-module is available to S-module internals during the XFERO Slave Controller state.
The msb of an S-module transmitted packet is transferred during the XFER16 Slave Controller state. The lsb of an S-module transmitted packet is transmitted during the first cycle of the MCLK signal in which the
7-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL I t € €
Std 1149.5-1995
S-module's S-Controller is in its XFERO Slave Controller state. Note that, subsequent to the transmission of an HEADER packet by the M-module, a packet transfer from the M-module is paired with a packet transfer from the uniquely addressed S-module. The S-module transmitted packet of such a pair begins transmission two cycles of the MCLK signal after start of transmission of the paired M-module transmitted packet (figures 7-2 and 7-4).
MCLK - -
- Bits of HEADER Packet - MMD
- Bits of S-module Packet
+2 cycles of MCLK signal
- MSD
+ NOTE-S-module packet transmission via the MSD signal begins two cycles of the MCLK signal after the correlated packet transmission from the M-module via the MMD and MCTL signals.
Figure 7-2-Time relationship of packets received by an S-module to packets transmitted by an S-module subsequent to transmission of a HEADER packet
PAUSE Slave Controller stute-The PAUSE Slave Controller state is the mechanism used to provide a mini- mum delay following each packet transfer within a message. This allows S-modules time to interpret the packet and respond as necessary. S-modules that implement the MPR signal may convey to the M-module the requirement for more time to be spent in the PAUSE Slave Controller state (3.1.1g; 3.1.2; 4.3.1~; figure 6-2 (second note); 6.3; 8.3; 9.3.1; table 9-4; 11.4.1). Once an S-Controller is in its PAUSE Slave Controller state, the interval between packet transfers may be extended by the M-module's holding MCTL released and MMD asserted. A Slave may signal an interrupt during the PAUSE e Controller state consistent with clause 10.
ERROR Slave Controller state-The S-Controller of an S-module enters the ERROR Slave Controller state when any of the following occur:
The M-module continues what appears to be transmission of packet bits (MCTL=l, MMD=X) for more than the specified 17 consecutive cycles of the MCLK signal. The M-module transmits insufficient bits to make up a packet-MC-1 with MMD=X for less than the specified 17 consecutive cycles of the MCLK signal. The S-Controller enters its EOM Slave Controller state; and, on the immediately subsequent falling edge of the MCLK signal, the registered values (figures 7-3 and 7-4) of the state transition control- ling signals are not both equal to logic 0.
Note that once an S-Controller has entered the ERROR Slave Controller state, the fsm will remain in that state (terminating S-module participation in the current message) until the registered values (figures 7-3 and 7-4) of MCTL and MMD are both 0. This allows resynchronization of the M-module and S-module follow- ing a faulty transmission.
When the S-Controller of an uniquely addressed S-module is in its ERROR Slave Controller state and the most recently detected State Sequence Error occurred during transmittal of a packet other than an HEADER packet, the S-module will assert the MSD signal (1 1.6.1 b). As a consequence, if the M-module is receiving a
7-5
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
packet from an S-module when that S-module's S-ControUer enters its ERROR Slave Controller state, the packet may have either even or odd parity.
Figure 7-4 illustrates the timing relationship of events relevant to state changes of the S-Controller.
1 MCTL-REG J
MMD MMD-LTCH MUD-REG 1D
-> c1 -> c 1
MSD
IS-XFER-STATE __---___. I S-Module I 1 LinkLayer 1
Controller I I I
I
I I
NOTE-Figure 7-3 illustrates a model of the operation of S-module input latching and registration. "New" values of MMD and MCTL are driven on the rising edge of the MCLK signal. On the immediately subsequent falling edge of the MCLK signal, this pair of values is latched and become the values of the signals laboled MMD-LTCH and MGTL-LTCH respec- tively. One half cycle of the MCLK signal later, the pair of values is registered and become the values of the signals labeled MMD-REG and MCTL-REG respectively. One full cycle of the MCLK signal later, the registered values affect the Slave Controller state of the S-module Link Layer Controller (S-Controller). Two full cycles of the MCLK signal have passed since the M-module originally drove the pair of values onto the MTM-Bus. To allow the first bit of S-module output data to be driven on MSD on the same edge of the MCLK signal in which the S-Controller enters the first S-transfer state (XFER16), the MCTL signal has to be ORed with the signal IS-XFER-STATE, which (in this model) signals that the S-Controller is in an S-transfer state. In this way, the first value to be driven on MSD in a given packet will be driven on the same rising edge of the MCLK signal on which the S-Controller enters its XFERl6 Slave Controller state. To simplify the illustration the MCLK signal is not connected to the registers receiving input data (S-module Input Data) or holding data ready for output (S-mod- ule Output Data). The Slave Controller states and state transitions of the S-Controller are unlikely to be directly observable in an S-module. This Standard specifies the observable behaviorof an S-module.
Figure 7-3-A model of S-module internals related to (1) S-module input value latching, (2) S-module registration of latched values, (3) S-module output driving, (4) the MCLK signal,
and (5) state transitions of the S-module's S-Controller
7-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
MCLK
b b”
NOTE-This diagram is an examp/eof operation of an S-module that would satisfy the requirements of this Standard (with Slave Controller state changes occurring as in the model of figure 7-3). It is not a required or recommended implementa- tion. The M-module begins to drive *new” values of MCTL and MMD consequent to the rising edge of the MCLK signal marked a. At the falling edge marked b, an S-module (S) latches the values on its MCTL and MMD signal inputs. These latched values are registered in the S-module at the rising edge marked a’ at the same that the “second” set of MCTUMMD values is driven by the M-module. At the falling edge marked b’, the “second“ set of MCTUMMD input values are latched by the S-module. The change of state of the S-modulo’s S-Controller that depends on the values driven by the M-module at a occurs on the rising edge marked a”. At this saint. lime. (1) Ihe oulpirt Iliiit Iho S-module is expected to generate during the newstate is driven, (2) the second set of values driven by the M-module is registered by the S-module. and (3) the M- module drives the ”third” set of MCTUMMD values. The process is repeated for a’-”’’, etc. Therefore, in this mode/, the Slave Controller state change to be caused by a pair of values on MCTL and MMD occurs two cycles of the MCLK signal after those values are driven onto the MTM-Bus. /n this mWe4 the values driven by an S-module while its S-Controller is in a given Slave Controller state are driven onto the MTM-BUS roughly simultaneously with the S-Controller‘s entry into that Slave Controller state. A change of state of the S-Controller may not be directly observable and, in any given implementa- tion might occur any time after the relevant MCTL and MMD values have been registered and prior to the rising edge on which the Slave Controller state change occurs in the model of figure 7-3. This Standard specifies the obsewab/e behavio/ of an S-module.
Figure 7-4-A model of the time relationship of Slave Controller state transitions to (1) S-module input value latching, (2) S-module registration of latched values,
(3) S-module and M-module output driving, and (4) the MCLK signal
7-7
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
7.2 S-module interface logic requirements
7.2.1 Specifications
(a) Physical layer requirements shall be met by an S-module’s NITM-Bus interface logic.
(b) All logic associated with addressability (3.3) of an S-module shall be included in its MTM-Bus interface logic.
(c) The S-Controller implementation of an S-module shall be included in its MTM-Bus interface logic.
(d) Logic necessary to implement interrupt generation (10.1) for an S-module shall be included in its MTM-Bus interface logic.
NOTE-In addition, 15.1.1 requires that the implementation of Core class commands in a given S-module be consid- ered part of its MTM-Bus interface logic. See 14.1.2 and 15.1.2.
7.2.2 Description
Subclause 9.1 requires that certain slave status registers have to be included in the MTM-Bus interface logic.
The following is a possible partition of error handling functions between the interface logic and the applica- tion of an S-module:
11.2: Self-Test Failure-application 11.4: Data Overrun Error-application 11.5: Parity Error-interface logic 11.6: State Sequence Error-interface logic 11.7: Collision Response-interface logic 11.8: Data Port Transfer Errors-application 11.9: Command Sequence Error-interface logic 11.10: Illegal command-interface logic (for Illegal command) and application for unimplemented
The above list was put together based on the concept that Physical and Link Layer capabilities are inherently a part of the interface logic while Message Layer functions need not be.
Core class commands are implemented by circuitry that might be a physical or virtual part of an S-module’s MTM-Bus interface logic (15.1.2). An S-module’s application logic may need to be aware of activity in [the state of (here not limited to mean Slave Controller state of)] that S-module’s MTM-Bus interface logic (14.1.1e; 14.1.2; 15.1.2).
7-8
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
8. MTM-Bus Link Layer: S-module requirements-general communications
8.1 S-module send and receive parity requirements
8.1.1 Specifications
(a) An S-module shall have the capability to detect bad parity of an M-module transmitted packet.
(b) Every packet transmitted by an S-module shall have good parity except when a State Sequence Error has occurred (7.1.1; figure7-1; 9.3.1; 9.3.2; 11.6.lb) or when the S-module is complying with aData Echo Test command (16.11.1) and echoing a packet that had bad parity as received.
NOTE&Since the MSD signal is asserted when a State Sequence Error occurs, there is no control over the parity that the M-module will read during the current packet transfer. Hence, the packet as received by the M- module has a chance of having bad parity.
8.2 S-module MSD signal general requirements
8.2.1 Specifications
(a) An S-module shall not assert the MSD signal unless
(i) it is uniquely addressed and in the process of transmitting a packet bit;
(ii) it is uniquely addressed and signaling the occurrence of a State Sequence Error;
(iii) it is addressed and participatin r Bus sequence (16.4.1) or responding to the Verify BMR (16.12.1) command;
(iv) it is attempting to transmit an interrupt to the M-module according to the specifications of clause 10.
8.2.2 Description
S-modules do not assert MSD during HEADER packet transfer because they have not yet been addressed. Once addressed, a ready S-module begins packet transmissions via the MSD signal two cycles of the MCLK signal after MCTL is first asserted at the start of an M-module packet transfer as described in clauses 6 and 7. If an S-module is being addressed via the broadcast address or a multicast address (3.3.1; 3.3.2), it does not source MSD, except when responding to the Contend for Bus (16.4.1) or Verify BMR (16.12.1) com- mand.
An S-module is required to assert the MSD signal upon the entry of that S-modules’s S-Controller into its ERROR Slave Controller state. This requirement is necessary because it is important that the M-module be able to detect an S-module’s signalling of an interrupt at the next time when the S-module would be expected to have its S-Controller in either its PAUSE or IDLE Slave Controller s ta teunder normal operat- ing conditions. When an S-Controller has entered its ERROR Slave Controller state, the S-module contain- ing that S-Controller cannot be assumed to be tracking MTM-Bus activity and cannot predict when the S- Controller would be expected to be in a particular Slave Controller state. Hence, the S-module cannot be selective with regard to timing of assertion of the MSD signal in order to create an interrupt. If an S-module
8-1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
always asserts the MSD signal while in its S-ControIlers’ ERROR Slave Controller state, the M-module will detect an interrupt at the earliest possible time. A further note: If the M-module is receiving a packet from an S-module when that S-module’s S-Controller enters its ERROR Slave Controller state, the packet may have either even or odd parity.
8.3 S-module MTM-Bus Pause Request (MPR) signal implementation (data transfer control) requirements
8.3.1 Specifications
An addressed S-module in which the MPR signal (4.3.1~) is implemented shall indicate its readiness or lack of readiness to continue message transmission by (respectively) releasing or asserting the MPR signal.
An S-module that is not addressed shall not assert the MPR signal.
An S-module that is asserting the MPR signal shall release the MPR signal upon entry of that S- module’s S-Controller into its EOM Slav
During and immediately following the packet other than a HEADER packet, if an S-module releases the MPR signal while the S-Coaln)llcr is ie any of thL: follo~vi~~g Slave Con- troller states (XFERI, XFERO, PAUSE, EOM, and IDI.E), tlie S-module sliall not :rsscri JIPR before the S-module’s S-Controller next enters its XFERlO Slavc Coiitrollcr svalc.
Immediately following the transmission of a HEADER p signal while
(i)
(ii) its S-Controller is in its PAUSE Slave Contro
i’
t?-if ’an S-module releases the MPR
its S-Controller is in its EOM or IDLE Slave Controller state
and at least two and one-half cycles of the MCLK signal have occurred since the last data bit of the given packet was latched at the S-module’s MMD input,
then the S-module shall not assert MPR before its S-Controller next enters its XFER16 Slave Con- troller state.
NOTE-If sufficient cycles of the MCLK signal are allowed after transmission of a HEADER packet and before the next M-module packet transmission ofthe current message (i.e.. three or more such cycles), two full cycles of the signal on MCLK are allowed for the S-module to become addressed and recognize a condition warranting assertion of the MPR signal. If only one or two cycles of the MCLK signal occur between trans- mission of a HEADER packet and the next packet of the same message, then either an addressed S-module has to assert MPR defensively during transmittal of the HEADER packet or be capable of accepting at least one packet before its pause request can be acted upon.
Recommendations
(f) If a given S-module implements the MPR signal, that S-module should assert the MPR signal in the module’s S-Controller’s XFER16 Slave Controller state and not release the MPR signal until the given S-module is ready to continue with transmission of the current message.
NOTES
I-Consider the case in which an M-Controller is programmed to remain in its PAUSE-01 Master Controller state for only one cycle of the MCLK signal between transmitting packets of a given message. It is a conse-
8-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
quence of 6.1.1 and figures 6-1,6-2, and 6-3 that, if the MPR signal is to be asserted by an S-module following the M-module’s transmission of a given packet, then the S-module has to validly drive a logic one on the MPR signal while that module’s S-Controller is in its XFERl Slave Controller state during the transmission of the given packet.
2-Consider the case in which an M-Controller is designedprogrammed to remain in its PAUSE-01 Master Controller state for 4 cycles of the MCLK signal after transmission of a HEADER packet (6.1.10). It is a con- sequence of 6.1.1 and figures 6-1,6-2, and 6-3 that, if the MPR signal is to be asserted by an S-module following the transmission of a HEADER packet with the intent of delaying transmission of the next packet of the current message, then the S-module has to validly assert the MPR signal while the S-module’s S-Controller is in its PAUSE Slave Controller state and less than three full cycles of the MCLK signal have passed since the last data bit of the HEADER packet was latched at the MMD input of the S-module.
8.3.2 Description
I I ,
MMD
MSD
I I
one MCLK cycle --+ k- -+ t w o ~ ~ ~ ~ c y c i e s MPR has to be asserted here in order to prevent a subsequent packet transfer f r o m 2 being started.
k- New packet transmission begins.
NOTE-If an addressed S-module needs to request additional time for its S-Controller to remain in its PAUSE Slave Con- troller state, that S-module has to assert the MPR signal at least three cycles of the MCLK signal before the MCTL signal is asserted with the M-Controller in its XFER16-1X Master Controller state (figure 6-2 and associated notes). In figure 8-1, it is assumed that the packet being transmitted at time a is not the last packet in a message. Having reference to figures 6-2,7-3, and 74, note that the value of MPR at a” will be latched by the M-module at b” and affect the M-Controller and M-module internals at a”’. If the M-module were programmed to allow only a single cycle of the MCLK signal between packet transfers, it would reassert the MCTL signal at a”’ if not prevented from doing so by a combination of assertion of the MPR signal and the M-module’s being programmed to respond to that signal. For the sake of illustration, it is assumed that a single S-module is asserting the MPR signal. When this module releases the MPR signal at the time marked a(5), the M-module may begin transmission of a new packet of data on the rising edge of the MCLK signal marked at6). Once the S-module’s S-Controller is in an S-transfer state, it is recommended that the module reassert the MPR signal; this oc- curs at c. S-module transmission of its new packet begins simultaneously. If the M-module of figure 8-1 was programmed to operate with a single cycle of the MCLK signal separating non-HEADER packets of a message, then the effect of the assertion of MPR in the figure is to delay transfer of a DATA packet by three cycles of the MCLK signal. In figure 8-1, the M-Controller enters its PAUSE01 Master Controller state at a” and its XFER16-1X Master Controller state at at6). The S- module in this example enters its XFERI Slave Controller state at a”, its PAUSE Slave Controller state at a(4), and its XFER16 Slave Controller state at a(*).
Figure 8-1-MPR signal timing
When an M-module is operating the MTM-Bus with a minimum of one cycle of the MCLK signal between transfer of packets, an S-module has to assert the MPR signal prior to the XFERO Slave Controller state of that module’s S-Controller to request of the M-module that the S-Controller be held in its PAUSE Slave Controller state, as shown in figure 8-1. The M-module may either wait until the MPR signal is released before transferring the next packet or “force” the transfer of an additional packet or “force” the S-module’s S-Controller to its IDLE Slave Controller state to terminate the message. If the current message is not termi-
8-3
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
nated in this manner, then for as long as the relevant S-module’s S-Controller remains in its PAUSE Slave Controller state, that S-module will continue to assert the MPR signal until it is ready to participate in the next packet transfer. If an S-module’s S-Controller is “forced” to its XFER16 Slave Controller state, then the S-module may continue to assert MPR with the possibility that the pause request may be honored by the M- module following the “forced” packet transfer. If an S-module’s S-Controller is “forced” to its IDLE Slave Controller state while that S-module is asserting the MPR signal, the S-module immediately has to release the MPR signal.
Note that the BSY bit in the Slave Status register (9.2.1) does not provide the same function as the MPR sig- nal. The BSY bit indicates that the module is still completing execution of a previously issued MTM-Bus command. This bit is examined when a HEADER packet is received to determine whether the command will be executed. The MPR signal, on the other hand, provides a mechanism for an S-module that functions slowly or has to retrieve data from a module resource that operates slowly (e.g., EEPROM) to control the flow of data between M-module and S-module. The MPR signal may also be used to slow down a message transfer if a necessary module resource is presently unavailable to the MTM-Bus.
8-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
9. MTM-Bus Link Layer: S-module requirements-status registers
An S-module records the following information in two or more status registers:
- certain programmable operating parameters - the occurrence of certain application-specific events - the occurrence of events requiring the sending of an interrupt to the M-module - other flags, codes, state information, etc.
The Slave Status register (9.2), the contents of which are returned in an ACKNOWLEDGE packet (5.3), contains basic Slave status and pointers to more detailed error information.
The Bus Error register (9.3) identifies specific types of errors that may be the cause of an interrupt. Such errors include errors in
The Module Status register (9.4) may contain both statbs information and error conditions that may be the cause of an interrupt.
Optional registers containing other module operational error and status information (9.5) are allowed if min- imum requirements for such registers are fulfilled.
9.1 S-module status registers-general requirements
9.1.1 Specifications
(a) Each S-module shall contain in its interface 1 described in 9.2.
its own (unshared) Slave Status register as
(b) Each S-module shall contain in its interface logic its own (unshared) Bus Error register(s) as described in 9.3.
(c) There shall be one Bus Error register for each MTM-Bus interface on a module (i.e., per set of five MTM-Bus signals).
(d) If 9.1.le is implemented, reading of data from the data backup means defined in 9.1.le shall not cause the alteration of that data as recorded in that backup means.
NOTELWhen a status register is read by the Read Status command, its contents are altered, in most cases by error bits being cleared. This is advantageous because new error conditions arising subsequent to the reading of the register (but still within the same message) will be recorded as new errors in the register without ambi- guity. However, if for some reason a register has to be "reread" in such a situation, the original data would be lost-if a shadow-register-type mechanism were not implemented. The Read Data command (17.2.1) can be used to gain access to data stored in such a shadow-register-type resource if an appropriate port is defined such as the recommended Error/Status Shadow Register port (21.9). Concern for security (i.e., consistent with the motivation behind 9.1.1e), requires that the contents of these resources should not be altered when they are read.
9- 1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Recommendations
(e) Whenever the Slave Status register, Bus Error register, or (if implemented) Module Status register of an S-module is read by a function that would alter the given register’s contents, the data read should be preserved by a means that allows repeated reads of the data via a port as defined in 21.9.
NO-It is reasonable to assume that the preservation of data in a register as described in the present recom- mendation occurs prior to the scanning of data from the register. Reading of data from the data backup means required if 9.1.le is implemented is made possible via the MTM-Bus by the implementation of suitable ports such as an Error/Status Shadow Register port (21.9) accessible by the Read Data command (17.2.1).
(f) Each S-module should contain in its interface logic its own (unshared) Module Status register as described in 9.4.
(g) Any additional status registers implemented according to 9.1.lh and 9.5.1 should be supported in the manner recommended for Slave Status, Bus Error, and Module Status registers in 9.1.le.
Permissions
(h) S-modules may contain and utilize additional status registers as described in 9.5.1.
9.1.2 Description
Suppose that during the transfer of d received by the M-module. Supposing
a Parity Error is detected on a packet to a sufficiently critical interrupt, which were apparently garbled in
that supplied by the Read Status command. When a status regi its contents are altered, in most cases by error bits being cleared nditions arising subsequent
s new errors in the register without ambiguity. If for some reason a register has ” in the above situation, the original data would be lost if a shadow register type mechanism w mplemented. The Read Data command (17.2.1) can be used to gain access to data stored in such a register-type resource if an appropriate port is defined as is recommended (21.8). Out of continued concern for security (i.e., consistent with the motivation behind 9.1. le),
- The contents of these resources sh ey are read. - The only Data Transfer class CO
Data command. rt of such a resource has to be the Read
9.2 Slave Status register
9.2.1 Specifications
(a) The layout of the Slave Status register of an S-module and the meaning of the bit positions in such a register shall be as defined in table 9-1.
(b) Power-up and reset values for the bits of the Slave Status register shall be as specified in table 9-2.
NOTELPower-up values for all MTM-Bus Status registers are the same values specified to be in those regis- ters as a result of executing the Reset Slave Status command (16.3.1).
9-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
Table 9-1-Slave Status register bit definitions
Name
Module Fail Status
Slave Busy
Event Occurrence
Bus Error
Multicast Select Bit I
Multicast Select Bit 0
Pause Interrupts Enabled
Idle Interrupts Enabled
- Mnm
MFS -
BSY
EVO
BSE
MSB 1
MSBO
PIE
IIE
-
~
Meaning (when set unless otherwise stated)
The S-module implements self-test and its self-test has failed or is not yet completed.
The S-module is executing a previously transmitted MTM- Bus command; or a process initiated via a port selected by a previously transmitted MTM-Bus command is executing; or the S-module is executing its power-up sequence, which may include self-test.
NOTE-The BSY bit is used to indicate that a command, C (the execution of which continues beyond the end of the message that transmitted C), or a process initiated by command C is executing and may affect accessibility of S-module status registers or other S-module resources.
An application-related condition requiring an interrupt has oc- curred [may be elaborated in the Bus Error register (bits 42 . . 15>), Module Status register or additional status regis- ters].
An error has been detected (elaborated in the Bus Error register).
This bit and the following (MSBO) together encode the mod- ule’s Multicast Address Group.
See above.
1) When addressed during a broadcast or multicast message, the S-module may generate an interrupt while its S-Controller is in its PAUSE Slave Controller state. 2) When nor addressed, the S-module may generate an inter- rupt while its S-Controller is in its PAUSE Slave Controller state if the IIE bit is set also.
The S-module may generate an interrupt while its S-Controller is in its EOM or IDLE Slave Controller state.
NOTE-This bit is set on power-up (table 9-2).
Key: PB = ACKNOWLEDGE packet bit number RB = Register bit number Mnm = Mnemonic
(c) If an S-module implements self-test (18.1; 18.2; 18.4), then the MFS and BSY bits of that S- module’s Slave Status register shall be set just prior to the initiation of self-test.
(d) In an S-module in which self-test is implemented (18.1; 18.2; 18.4), the MFS and BSY bits of the Slave Status register shall remain set throughout the self-test operation.
(e) In an S-module in which self-test is implemented (18.1; 18.2; 18.4), both the MFS and BSY bits shall be cleared immediately following a self-test in which no faults are detected.
NO’E-Response to self-test failure is treated in 11.2.1 and 18.1.lb.
(f) Except as required by 9.2.1b-d and 11.2.1a, the BSY bit in the Slave Status register of a given S-module shall be set only while the S-module is executing an MTM-Bus command and shall be cleared upon completion of such command execution.
9-3
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
Table 9-2-Values of Slave Status register bits at power-up and after reset
after reset*
4
Key: PB = ACKNOWLEDGE packet bit number RB = Register bit number Mnm = Mnemonic
*Reset is defined to be the condition of the S-module MTM-Bus Interface circuitry after execution by the S-module of the Reset Slave Status command (16.3.1).
(g) The BSE bit in the Slave Status register of a given S-module shall be set if the logical OR of the error bits (9.3.la; 9.3.le; table 9-4) in the Bus Error register equals a logic 1.
NOTFG-Not all bits in the Bus Error rcglstcr arc crror bits. The BMR bit is an example of a non-error bit, and its value is not input to the logiciil O K rcriiiircd hy 9.2.lg. User-defined bits in the Bus Error register may or may not be error bits.
(h) The EVO bit in the Slave Status register of a given S - dule shall be set if a logical OR driven by both of the following:
(i) all error bits of the Module Status register 19.4)
(ii) a bit in the Module Status register indicating self-test failure or a logical AND of the MFS bit of the Slave Status register with the inverse of the BSY bit of the Slave Status register
equal logic 1.
NOTES
l--Other bits of the Module Status register or of additional registers may drive the logical OR required by this rule (9.2.1j; 9.2.lk).
2-9.2.lh(ii) means that the EVO bit will be set if a self-test procedure of an S-module fails (11.2.1).
(i) The state of the Slave Status register of a given S-module shall not change as a consequence of that S-module’s returning an ACKNOWLEDGE packet (5.3.1).
9-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
Permissions
(i) The logical OR driving the BSE bit in the Slave Status register of a given S-module (9.2.lg) may be driven by
(i) ’ user-defined bits of the Bus Error register (bits <12..15>)
(ii) bits of the Module Status register
(iii) bits of additional status register
that are documented to do so by the S-module’s manufacturer.
(k) The logical OR driving the EVO bit in the Slave Status register of a given S-module (9.2.lh) may be driven by
(i) user-defined bits of the Bus Error register (bits <12..15>)
(ii) bits of the Module Status register
that are documented to do so by the S-module’s manufacturer.
(1) The logical OR driving the EVO bit in the Slave Status register of a given S-module (9.2.lh) may be driven by any bits of additional registers (9.5) that are documented to do so by the S-module’s manufacturer.
9.2.2 Description
Table 9-2 defines the state of the Slave Status register at power-up and reset. The reset condition of the MTM-Bus Interface circuitry of an S-module is defined to be the condition of that circuitry after the S-module has executed the Reset Slave Status Command (16.3.1). The set of MTM-Bus commands defined in this Standard that result in a reset of the Slave Status register are as follows:
- Reset Slave Status command (16.3.1) - Reset Module with SBIT command (18.2.1) - Reset Module without SBIT command (1 8.3.1) - Module IBIT command (18.4.1)
The Read Status command (16.1.1) will always cause at least the reading of the Slave Status register.
In the Reset Module with SBIT and Module IBIT commands, if the self-test initiated by the command fails, the reset will not be achieved because MFS will be set as a result of the failure (11.2.1).
Module Fail Status bit -If an S-module implements self-test, the MFS and BSY bits of its Slave Status reg- ister have to be set at the initiation of a self-testing sequence (9.2.1~). Once self-testing is complete, the BSY bit is released and the MFS bit is cleared if the self-test detected no faults (9.2.le). Actions taken in case a fault is detected are treated in 11.2.1. If an S-module does not implement self-test, the MFS and BSY bits of its Slave Status register have to be cleared at power-up and when the S-module MTM-Bus Interface circuitry is reset (9.2.lb; table 9-2).
Slave Busy bit -When set, the BSY bit (bit <6>) indicates that the addressed S-module’s application logic is busy executing a previously loaded MTM-Bus command or a start-up sequence that may include self-test. While the BSY bit is set, the S-module can still respond to the Core class commands (15.1; clause 16). The BSY bit will be cleared when an MTM-Bus command execution or a module self-test sequence is com-
9-5
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
pleted. If a module contains a power-up self-test procedure (18.2), BSY will be set at the initiation of the test procedure and cleared at the test completion, regardless of outcome (9.2.le; 11.2.la).
Event Occurrence bit -When set, the EVO bit (bit 6>) indicates that a module application-related event has occurred. Such an event may be further characterized by information in either the Module Status register (9.4) or in additional status registers (9.5). A logic 0 to logic 1 transition of any error bit (9.4.la) in the Mod- ule Status register will cause the EVO bit to be set (9.4.lb). Setting the EVO bit will cause an interrupt to be generated consistent with 10.1.1. Note that application-defined bits of the Bus Error register (bits <12..15>), Module Status register andor additional status registers may also be input to the logical OR that sets the EVO bit, as detailed in a given S-module’s specifications.
Bus Error bit -When set, the BSE bit (bit <4>) indicates that an error has been detected as elaborated in the Bus Error register (9.3). If the logical OR of the error bits (bits <9..0>) of the Bus Error register equals logic 1, this will cause the BSE bit to be set. Note that application-specific error bits of the Bus Error register (bits <15..12>) may also be input to the logical OR that sets the BSE bit, as detailed in a given S-module’s speci- fications.
Multicast Select bits-The MSl and MSO bits (bits <3..2>) indicate to which one of the four multicast address groups (table 9-3) the S-module will respond. These bits are set as defined for the Multicast Select 0, 1 ,2 ,3 commands (16.5.1).
d their addresses
Pause Interrupts Enabled bit -An uniqu ay always signal an interrupt when it S-Controller is in its PAUSE Slave Contr elevant to interrupt operation while an S-module is addressed via multicast or br le is not addressed (table 10-1). When set, the PIE bit (bit <1>) indicates that the S-module is enabled to interrupt while its S-controller is in its PAUSE Slave Controller state (figure 7-1 and table 10-1) when the S-module is addressed during a broad- cast or multicast message. When an S-module is not addressed, it is enabled to interrupt when its S-Controller is in its PAUSE Slave Controller state only if both the PIE and the IIE bits are set. This interrupt capability is further defined in 10.1.1. The PIE bit is set as defined for the Enable Pause Interrupts command (16.7.1). The PIE bit is cleared as defined for the Disable Pause Interrupts command (16.9.1).
Idle Interrupts Enabled bit -When set, the IIE bit (bit <O>) indicates to the M-module that the S-module is enabled to interrupt when its S-controller is in its EOM and IDLE Slave Controller states (figure 7-1; table 10-1). This interrupt capability is further defined in 10.1.1. The IIE bit is set as defined for the Enable Idle Interrupts command (16.6.1). The IIE bit is set on power-up; this enables S-modules that power-up with some problem to signal an interrupt as early as possible. The ID3 bit is cleared as defined for the Disable Idle Interrupts command (16.8.1).
The Slave Status register state is returned as part of the ACKNOWLEDGE packet (5.3.1) and as the first data packet in response to the Read Status command (16.1.1). When the Slave Status register state is
9-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
returned as part of the ACKNOWLEDGE packet, the data in the Slave Status field of that packet will not reflect any status changes due to the command received in the HEADER packet of the current message.
9.3 Bus Error register
9.3.1 Specifications
(a) The layout of a Bus Error register of an S-module and the meaning and use of the bit positions in such a register shall be as defined in table 9-4.
(b) Power-up and reset values for Bus Error registers shall be as specified in table 9-5.
NOTE-Power-up values for all MTM-Bus Status registers are the same values specified to be in those regis- ters as a result of executing the Reset Slave Status command (16.3.1).
(c) Bus Error register bit <11> shall be reserved for future definition by this Standard and, after being cleared at power-up according to 9.3.lb, shall remain at a logic 0.
(d) All unimplemented user-defined bits, after being cleared at power-up according to 9.3.lb, shall remain at a logic 0.
(e) If 9.3.lh is implemented, then the user-defined bit in question shall be an input to the logical OR forming EVO.
Permissions
(f) Any user-defined bit (bits <15..12>) may be used to indicate application-specific MTM-Bus related errors.
(g) Any user-defined bit (bits <15..12>) may be used to indicate module-specific status information.
(h) In an S-module implementing a port interfacing to IEEE Std 1149.1 boundary-scan (21.10) and implementing the Trigger on Event capability (21.10.ld; 21.10.lf through 21.10.lh; 21.10.ln), an indicator for the Occurrence of a trigger event may be implemented as a user-defined bit in the Bus Error register.
(i) The indicator for completion of an S-module’s self-test (11.2.1; 18.1.1; 18.2.1; 18.4.1) may be
(i) implemented as a bit in the Bus Error register of that S-module;
(ii) designed to drive the logical OR feeding the EVO bit of the Slave Status register (9.2.1).
NOTE-To know that a self-test has completed without detection of a failure, two indicators are required-the fact that the MFS bit of the Slave Status register has not been set is insufficient evidence of lack of failure. If an indicator of self-test failure (such as the MFS bit) is not set by a self-test procedure, it may indicate either that the self-test completed without detection of failure or that the self-test terminated for some reason without having detected a failure. See also 9.4.le.
9.3.2 Description
The Bus Error register identifies the type of error that has caused a given S-module’s Slave Status register BSE bit to be set. It also provides status information related to receipt of broadcast and multicast messages.
9-7
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Table 9-4-Bus Error register bit definitions
PB
16 (msb)
15
14
13
12
11
Key:
11 1 Reserved
10 I BroadcastMulticast Received
PB = ACKNOWLEDGE packet bit number
BMR
-
Meaning (when set unless otherwise stated)
User-defined
User-defined
User-defined
User-defined
Undefined
A previously transmitted broadcast or multicast HEADER packet was received without error. Shall be (shall have been) set when an addressed S-mod- ule’s S-Controller is in its EOM Slave Controller state when no error was detected during receipt of the HEADER packet of a then current broadcast or multicast message un- less that HEADER packet included the command code of the Verify BMR command and the dchition of the com- mand (16.12.1) requires the bit not to be set. Shall not be set during a broadcast or multicast message ex; cept as just specified, above.
NOTES
1 -Following successfully transmitted messages conveying simple. commands (12.1.1, figure 12-1) that reset an S- module, this bit will not be set hecause the cxecution of a command occurs after the setting of the BMR bit (14.1.1f).
2-To use the BMR bit to check for successful transmission of a particular broadcast or multicast HEADER packet, the
bit has to be cleared after the end of transmission of any previous broadcast or multicast message.
RB = Register bit number- Mnm = Mnemonic
9-8
IEEE Std 1149.5-1995 MAINTENANCE BUS (MTM-BUS) PROTOCOL
Table 9-4-Bus Error register bit definitions (Conthwed)
- Mnm
SDF - Name Meaning (when set unless otherwise stated) PB
10 -
9
~~ ~~ _ _ _ _ ~ ~ ~~
While addressed, the S-module detected a collision fault (4.3.1; 11.7.1) on its MSD signal connection while both the following were true:
The S-module’s S-Controller was in one of its S- transfer states. The S-module was not responding to either the Contend for Bus or the Verify BMR command.
- -
Slave Data Fault
Command Resource Unavailable A resource required to execute a previously received com- mand was unavailable at the time the HEADER packet containing the command code of that command was received or (in the case of a Data Transfer class command) at the time the PORT ID packet of the relevant message was received; and the command was not executed (1 1.12.1). Shall not to be used to indicate partial completion of a com- mand.
CRU
IPC 8 7 Incorrect Packet Count At least one of the following holds: - The S-module implements the packet counting
function (14.2.1) and has detected that the actual number of packets transferred in a message is dif- ferent from the number indicated in the PACKET COUNT packet included in that message. The S-module implements the packet counting function (14.2.1) and has received a message con- sisting only of a HEADER packet in which the Acknowledge Request bit was set and in which the Command field did not contain the command code of the Data Echo Test command (16.11.1). The S-module has received a message consisting only of a HEADER packet, and the Command field of that packet contained the command code of either the Contend for Bus (16.4,l) or the Ver- ify BMR (16.12.1) command.
NOTE-When the Acknowledge Request bit is set in a HEADER packet and a single glitch on the MCTL signal causes an S-module’s S-Controller to fail to enter its XFER16 Slave Controller state (i.e., either to remain in its PAUSE Slave Controller state or to enter its EOM Slave Controller state instead), the subsequent packet will not be received. If this packet were the PACKET COUNT packet, an Incorrect Packet Count error cannot arise. However, the error just described will be detected as a State Sequence error (figure 7-1).
-
-
7 6 Illegal Port Selected IPS A logical port address to which data was directed is not supported (11.8.1a).
5 - 4
Port Transfer Error m A selected port has reported a Port Transfer Error (1 1.8. lb; 11.8.1~).
6
5 ~~ ~
Command Sequence Error CSE A critical control command was received, but was not im- mediately preceded by an Enable Module Control com- mand (11.9.1; 16.10.1).
Key: PB = ACKNOWLEDGE packet bit number RB = Register bit number Mnm = Mnemonic
9-9
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Table 94-Bus Error register bit definitions (Cunfinued)
PB RB Name Mnm Meaning (when set unless otherwise stated) I I 4 1 3 I IllegalCommand An illegal command was received (1 1.lO.l)- an unimple- mented command, a Reserved command, or the Illegal command (16.17.1).
I 3 I 2 1 ParityError ~~ 1 pm 1 A Parity Error was detected on a received packet (11.5.1).
1 DOR Data was transmitted to the S-module when the S-module was not ready to receive data (1 1.4.1).
Data Overrun Error 2
The S-module’s S-Controller entered its ERROR Slave Controller state (7.1.1; figure 7-1; 11.6.1). I SSE I 1 (l;b) 1 0 1 StateSequenceError
Key: PB = ACKNOWLEDGE packet bit number RB = Register bit number Mnm = Mnemonic
See clause 11 for information on error handling including requirements on manufacturer documentation concerning when Bus Error register ts in the Bus Error register may be used for module specific status indicators.
Table 9-5 defines the state of thc nu defined in this Standard that always rc
t. The set of MTM-Bus commands It i n :I rcsct of the Bus Error register are as follows:
- Reset Module without SBIT command (18.3.1) - Module B I T command (1 8.4.1)
Execution of the Read Status command (16.1.1) wi
message, then the Bus Error register will be cleared as a result.
f any register that is read during S-module during a Read Status
User-dejined bits -Bits<l5..12> of the Bus Error register may bc used for module or application-specific purposes. A user-defined bit may record an occurrcnce that should be flagged as an error or may be used as a module-specific status indicator. These bits may CilUSC the RSB tiit of the Slave Status register to be set, thereby signaling an interrupt consistent with 10.1. The operation of these bits (i.e., the causes for setting/ clearing them and instructions that setklear them) has to be documented in an S-module’s manufacturer’s specifications. If these bits are not used, they have to be set to logic 0 at power-up and remain at logic 0.
Resewed bit -Bit <11> is reserved for future definition by the IEEE Std 1149.5 working group. This bit has to be set to logic 0 at power-up and remain at logic 0. This bit will not be used for any other purposes.
BMR bit -Bit <lo>), when set, indicates to the M-module that the S-module received the HEADER packet of the last broadcast or multicast message without error. After a broadcast or multicast message, the BMR bit may be checked by reading the Bus Error register of each S-module or by use of the Verify BMR command. The BMR bit is useful in this context because [with the exception of the Contend for Bus (16.4.1) and Verify BMR (16.12.1) commands] no ACKNOWLEDGE packet is sent during a broadcast or multicast message; and, for some commands, the effects of successful receipt of a HEADER packet and consequent execution of the command transmitted in it may not be easy to observe. Thus the BMR bit allows detection of a situa- tion in which an S-module receives a HEADER packet, but does not respond as if it were addressed and, consequently, does not execute the transmitted command‘and ignores data transmitted in any DATA packets
9-10
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
of the message in question. Prior to transmission of a broadcast or multicast message, care should be taken that the BMR bit is cleared in all S-modules expected to partkipate in the message (11.3). Despite error-free multicast or broadcast transmission of a HEADER packet, the BMR bit of an addressed S-module’s Bus Error register will be cleared after the execution of simple commands (12.1.1; figure 12-1) that reset addressed S-modules (14.1.10.
Error bits-The error bits (bits <9..0>) in this register serve to clarify the type of error signalled by the BSE bit of the Slave Status register. The BSE bit of an S-module’s Slave Status register is set by the output of a logical OR of the error bits and, optionally, user defined bits in the Bus Error register. A description of each error bit is provided in the following paragraphs. Clause 11 details the S-module response when errors are encountered. Clause 11.1.1 specifies requirements on manufacturers of S-modules with regard to documen- tation of the timing of the setting of error bits following detection of an error, interrupt latency, etc. Table 9-4 summarizes the necessary conditions for setting the error bits in the Bus Error register. Table 9-6 summa- rizes the relation of the bits in the Bus Error register to rules governing error handling, Slave Controller states that are the earliest in which a relevant error might be detected, and packet types the flawed transmis- sion or reception of which might give rise to a relevant error.
Slave Data Fault bit -When the SDF bit (bit <9>) is set, this indicates that a collision fault (4.3.1) has been detected on the MTM-Bus MSD signal. An S-mdule i s required to provide collision-detection circuitry for the MSD signal. The collision-fault detection causes SDF to be set if the fault is detected while the S-mod- ule’s S-Controller is in an S-transfer state and the command being processed is neither (11.7.1) the Contend for Bus (16.4.1) nor the Verify BMR (16.12.1) command.
Command Resource Unavailable bit -The CRU bit (bit <8>), when set, indicates that a module application resource that is required to complete execution of a received command is unavailable and that the command has not been executed. The CRU is not to be used to indicate partial command completion. The CRU bit is set by an S-module following a HEADER packet containing the command code for the command, C, in its Command field when any of the following conditions are true:
a) b)
A necessary resource (e.g., a command processor) is unavailable. A resource required for the execution of C is unavailable and, thus, C cannot be executed.
NOTE-This situation may occur during an S-module’s attempt to execute a Module U0 Control and Test class, Module Initialization and Self-Test class, gr‘User class command (15.1).
c) The S-module receives a Data Transfer class or Module YO and Control class MTM-Bus command (15.1) while a previous MTM-Bus command is still in progress (i.e., the BSY bit of the Slave Status register is set).
If an S-module receives a Data Transfer class command (15.1.1a; table-15-l), the Port Identifier of the port to which data are directed will be transmitted in a DATA packet called a PORT ID packet (17.1.1a). In such a case, the CRU bit will be set by a receiving S-module following receipt of the relevant PORT ID packet (17.1.1a), if the requested resource (e.g., fault log port) is unavailable.
Incorrect Packet Count bit -The IPC bit (bit <7>), when set, indicates to the M-module that the S-module implements the packet counting function (14.2.1) and has detected that the number of packets transmitted following the PACKET COUNT packet did not correspond to the number identified in the PACKET COUNT packet (1 1.11.1). The IPC bit is set after the S-module’s S-Controller has entered its EOM Slave Controller state while the number of packets transferred since the PACKET COUNT packet is less than the number provided in the PACKET COUNT packet of the current message. The IPC bit is set after the S-mod- ule’s S-Controller enters its XFERl6 Slave Controller state while the number of packets transferred since the PACKET COUNT packet is equal to the number provided in the PACKET COUNT packet of the current message.
9-11
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Illegal Port Selected bit -The IPS bit (bit <6>), when set, indicates to the M-module that the Port Identifier contained in the PORT ID packet (17.1.1a) of a Data Transfer class command message is not supported by the S-module (1 1.8. la). A list of all ports supported by a module will be provided in the module documenta- tion. The IPS bit is set following transmission of the PORT ID packet, if the Port Identifier contained therein is invalid.
Port Transfer Error bit -The PTE bit (bit d>), when set, indicates that one of the following conditions has occurred:
a) The port selected during a Data Transfer class command message has reported an error (11.8.1b). The PTE bit may be set during or following receipt of any DATA packet (including the PORT ID (17.1.1a) packet), if the selectedport has detected an error. The S-module’s S-Controller enters its XFER16 Slave Controller state, and the S-module is not pre- pared to transmit a non-NULL DATA packet although one would ordinarily be expected at the time (1 1.8.1~) and the reason for the problem is not a Data Overrun Error (11.4.1). The only exception is in the case of packets returned in response to the Read Status command. It arises if the S-module is forced to transmit more packets than it has status registers. In this case the S-module returns NULL packets.
b)
Command Sequence Error bit -The CSE bit (bit <4>), when set, indicates to the M-module that the S-mod- ule detected an error in command sequencing. The CSE bit is set following receipt of a HEADER packet when any one of the following conditions occurs:
The S-module received a command requiring the (16.10.1), without rcceiviiig the EMC command in the immediately preceding message (11.9.lb). The S-module receiwd thc E command (11.9.la).
Command bit -The ILC bit
le -Module Control (EMC) command
nd followed by a command that did not require the EMC
>), when set, indicates to the M-module that the S-module received the Illegal Command (16.17. l), a Reserved command, or an unimplemented command (1 1.10.1). The ILC bit is set following receipt of a HEADER packet containing the Illegal command.
Parity Error bit -The PRE bit (bit e>), when set, indicates M-module that the S-module received a DATA packet, NULL packet, or PACKET COUNT packet with incorrect parity (11.5.lb). Note that the PRE bit is not set when the S-module receives a HEADER packet with incorrect parity (11.5.la).
Datu Overrun Error bit -The DOR bit (bit <I>), when set, indicates to the M-module that the S-module was unprepared to transfer a packet when the S-module’s S-Controller entered its xFER16 Slave Controller state. If a given S-module implements the MPR signal to control data flow f rodto the M-module, the DOR bit is set after the S-module’s S-Controller enters its XFER16 Slave Controller state while the S-module is asserting the MPR signal (11.4.la). In some instances, an S-module not implementing the MPR signal may require additional time to make data available for transfer on the MTM-Bus. If the M-module’s M-Control- ler enters its XFER16-1X Master Controller state before such an S-module is ready to transfer data, a Data Overrun Error will occur (11.4.1b).
State Sequence Error bit -The SSE bit (bit <O>), when set, indicates to the M-module that the S-module detected a State Sequence Error-its S-Controller has made a transition to the ERROR Slave Controller state (7.1.1; figure 7-1; 11.6.1).
9-12
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
Table 9-+Values of Bus Error register bits at power-up and after reset
Mnm
-
BMR
SDF
CRU
IPC
IPS
CSE
ILC
PRE
DOR
SSE
Values at power-up and after resetd ~ ~ ~ ~
0 (if unused) User-defined (otherwise)
0 (if unused) User-defined (otherwise)
0 (if unused) User-defined (otherwise)
0 (if unused) User-defined (otherwise)
0
0
0
0
0
0 -
0
0
0
0
0
0
ACKNOWLEDGE packet bit number Register bit number = Mnemonic
*Reset is defined to be the condition of the MTM-Bus Interface circuitry after execution by the S-module of the Reset Slave Status command (16.3.1). SDF, IPC, PRE, DOR, or SSE may be set after an attempted reset if the relevant error occurred during the mes- sage that was supposed to cause reset.
9-13
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Table 9-6-Summary of criteria for setting Bus Error Register Error bits
Slave ContmlIer state@ in which S-Controller may
reside when erroreondition- causing bit to be set will be
detected
Packet type(s), flawed reception or transmission of which may
cause bit to be set register bit to be
I set
I BMR 9.3.la PAUSE HEADER
Any state, S, such that a packet bit is expected to be transmit- ted while the S-Controller is in S--xFER16 through XFERO.
ACKNOWLEDGE (except during a Contend for Bus sequence or in response to the Verify BMR command), DATA
11.7. la SDF
11.12.la, I CRU 11.12.lb
PAUSE HEADER,PORTID (17.1.1a)
I
XFERl6, EOM DATA ll*llsa* 1l.ll.lb I IPC
PAUSE PORTID (17.1.1a) 11.8.la IPS
11.8.1b, FTE 11.8.1~
PAUSE, XFER16 Data Transfer Port Errors may be caused by prob- lems within the S-module rather than by a packet re- ceived by the S-module. HEADER, ACKNOWLEDGE, DATA-in the case of an ermr such us that described in 11.8.1~. DATA (following and not including a PORT ID packet (17.l.la))--in the case o fan error such as that described in 11.8. I b.
. . . ~
PAUSE HEADER 11.9. la, I CSE 11.9.1 b
PAUSE HEADER
ACKNOWLEDGEPACKET COUNT, DATA -
11. I O.la ILC
IlS.la, 11.5.lb
PAUSE
11.4. la, I DOR 11.4. l b
ACKNOWLEDGEPACKET COUNT, DATA xFER16
ERROR AWOWEDGJYPACKET COUNT, DATA 11.6.1a,
NOTES l-Each error bit is set when the related error condition occurs. This table identifies when the error bit can be set in relationship to the MTM-Bus Link Layer and Message Layer. A given error bit in a given S-module may be set in an S-Controller state subsequent to those appearing in this table. This is related to S-module processing time and num- bers of cycles of the MCLK signal that are allotted between packets of a message in a given system. Further details of timing (e.g., error latency) will be in an S-module manufacturer’s user documentation (11.1.1). 2-The PORT ID packet is a DATApacket with a special use defined by 17.1.la.
9-14
IEEE Std 1149.5-1995 MAINTENANCE BUS (MTM-BUS) PROTOCOL
9.4 Module Status register
9.4.1 Specifications
Rules
(a) Bits of the Module Status register shall be identified as to whether they are inputs to the logical OR forming EVO (9.2.1h) or that forming BSE (9.2.lg).
(b) The manufacturer of an S-module shall document the state of the Module Status register following power-up and after reset (i.e., execution of the Reset Slave Status command (16.3.1)).
(c) The state of an S-module’s Module Status register following power-up shall be the same as its state following execution of the Reset Slave Status command (16.3.1).
(d) In an S-module implementing one or more ports interfacing to IEEE Std 1149.1 boundary-scan (21.10) and implementing the Trigger on Event capability (21.10.ld; 21.10.lf through 21.10.lh; 21.10.ln) for some such port,
(i) an indicator for the occurrence o f a trigger event shall be implemented as a bit in the Module Status register if not implemented as a user-defined bit in the Bus Error register (9.3.lg);
(ii) that Module Status register bit shall be an input to the logical OR driving EVO (9.2.lh).
Recommendations
If a self-test completion indicator bit is not implemented in the Bus Error register of an S-module implementing self-test (9.3.1 i), then the indicator for completion of an S-module’s self-test (11.2.1; 18.1.1; 18.2.1; 18.4.1) should be
(i) implemented as a bit in thc Module Status register of that S-module;
(ii) designed to drive the logical OR fccding the
-.
0 bit of the Slave Status register (9.2.1).
N O W T O know that a self-test has completed without detection of a failure, two indicators are required-the fact that the h4FS bit of the Slave Status register has not been set is insufficient evidence of lack of failure. If an indicator of self-test failure (such as the MFS bit) is nor set by a self-test procedure, it may indicate either that the self-test completed without detection of failure or that the self-test terminated for some reason without having detected a failure.
Permissions
(f) A mask register may be implemented to provide bit-level masking of the Module status register inputs to the logical OR driving the EVO bit (9.2.lh).
9.4.2 Description
The Module Status register contains status and error information that is used by all MTM-Bus modules. The register contents are as defined below. Data contained in Module Status register are used to clarify the Slave Status register EVO interrupt.
The S-module manufacturer’s documentation has to identify each Module Status register bit as an error bit or a status bit. Error bits drive the logical OR driving the EVO bit of the S-module’s Slave Status register (9.2.lh). Error bits will be cleared as defined for the Reset Slave Status command (16.3.1), the Reset Module
9-15
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
with SBIT command (18.2.1), the Reset Module without SBIT command (18.3.1), and the Module IBIT command (18.4.1).
Execution of the Read Status command (16.1.1) will result in the clearing of any register that is read during execution of the command. If three or more packets are transmitted by an S-module during a Read Status message, then an implemented Module Status register will be cleared as a result.
The states of bits identified as status bits may or may not cause the EVO bit to be set (9.2.1k). The meaning of each status bit and the conditions causing it to be set and cleared have to be provided in the S-module’s documentation (1 1.1.1).
9.5 Additional status registers
9.5.1 Specifications
(a) The manufacturer of an S-module shall document any error bits contained within that S-module’s additional status registers that drive the logical OR driving the EVO bit of the S-module’s Slave Status register (9.2.lh).
(b) The manufacturer of an S-module shall document the state of an additional status register following power-up and reset (i.e., execution of the Reset Slave Status command (16.3.1)).
(c) The manufacturer of an S-module shall document the meaning of each bit in an additional status reg- ister.
(d) If the reading of an additional status register causes any of its bits to change state, this shall be described in the S-module’s documentation.
Recommendations
(e) The contents of additional status registers should be accessible via Data Transfer read commands.
(f) The contents of additional status registers should be returned in response to a Read Status (16.1.1) command as defined in 16.1.1~.
Permissions
(g) An additional status register may be used as the location of state variables required for the operation of Data Transfer ports (clause 21) such as any of the following:
(i) A flag recording that a given S-module has an active Disable Module I/O command (19.2.1);
(ii) A flag indicating that an S-module’s module outputs are not under control of non-test (normal operation) functions (19.4.1; 19.8.1; 19.9.1);
(iii) A set of bits used to track the controller state of a selected TAP in the case of an IEEE Std 1149.1 Interface port (21.12.1);
(iv) A flag to record whether or not the trigger is set in the case of an EEE Std 1149.1 Interface port having the Trigger on Event capability (21.10.1).
9-16
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
9.5.2 Description
A condition causing a bit in an S-module’s additional status register to be set may cause the EVO bit of that S-module’s Slave Status register to be set (9.2.lh; 9.2.11). Complete documentation of additional status reg- isters has to be provided. This documentation has to include register bit definitions, power-up values, set/ clear conditions, etc. If bits of an additional status register are used to record error conditions, manufactur- er’s documentation has to provide information required by 11.1.1.
Execution of the Read Status command (16.1.1) will result in the clearing of any register that is read during execution of the command. Any additional status register read during execution of the Read Status command will be cleared as a result.
9-17
IEEE Std 1149.5-1995
10. MTM-Bus Link Layer: S-module interrupt generation
There are two types of interrupt generation required of an S-module:
- interrupts due to State Sequence Errors (7.1.1; figure 7-1; 11.6.1b) (which cause an S-module’s S- Controller to enter its ERROR Slave Controller state and immediately assert MSD-essentially asserting an interrupt early to be sure that it will be asserted when the M-module is permitted to rec- ognize it);
- interrupts in response to the BSE or EVO bits being set in the Slave Status register (9.2.1).
In the case of a State Sequence Error, the interrupt may be generated while the M-module is expecting to receive a packet bit on the MSD signal. At least until the next time that the interrupting S-module’s S-Con- troller enters its IDLE Slave Controller state, that S-module will be constantly asserting the MSD signal- very probably producing meaningless transmission of apparent packet bits to the M-module. Once an S- module’s S-Controller is no longer in its ERROR Slave Controller state, interrupt generation caused by a State Sequence Error is subject to the same requirements as an interrupt provoked by any other error. The immediate response of an S-module to detection of a State Sequence Error is treated in 11.6.1.
Interrupt generation of the second type is specifjdd in the present clause. Interrupts specified in this clause are not generated at times when the M-module is expecting to received a packet bit on the MSD signal.
10.1 Interrupt generation other than immediate response to a State Sequence Error
10.1.1 Specifications
(a) The means by which an S-module shall signal an interrupt shall be the continuous assertion of the MSD signal.
(b) An S-module shall signal an interrupt when its S-Controller is in an appropriate Slave Controller state as defined by table 10-1 and the supporting note and either the EVO or the BSE bit is set in that S-module’s Slave Status register.
NOTES
1-During a broadcast or multicast message, interrupts are allowed when an S-module’s S-Controller is in its PAUSE Slave Controller state only if the PIE bit in the Slave Status register is set. The MSD signal will not be driven by the S-module during S-transfer states of a multicast message except (a) in response to the Contend for Bus or Verify BMR command or (b) immediately following detection of a State Sequence Error (8.2.1). 2-The conditions described in 11.6.lb compel an interrupt to be generated.
(c) An S-module shall consider an interrupt condition to be serviced when the EVO and BSE bits in its Slave Status register are cleared.
10.1.2 Description
An S-module having an interrupt pending (i.e., EVO or BSE bit set in the S-module’s Slave Status register) will signal an interrupt during its S-Controller’s PAUSE, IDLE, or EOM Slave Controller states if enabled to do so. The IIE bit in the Slave Status register and the PIE bit in the Bus Error register determine whether an S-module is enabled to interrupt or not. An uniquely addressed S-module may interrupt during any time when its S-Controller is in its PAUSE Slave Controller state, regardless of the values of IIE and PE.
10-1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
IIE and PIE only affect interrupt generation by enabling or disabling S-module interrupts for specified Slave Controller states and do not affectpending interrupt status (i.e., EVO and BSE bits).
The operation of IIE and PIE bits are as defined in table 10-1.
Table 10-1-Function of IIE and PIE bits in determining interrupt behavior of an S-module
not addressed
, , I
1 0 Pausdidle Idle Idle
1 1 Pausdidle Pauselidle Pauselidle
NOTE-The entry “pause” in a cell of the above table indicates that, if a given S-module’s Slave Status regis- ter has its ID3 and PIE bits set as in the two left-most columns of the given cell’s row, that S-module may source an interrupt when its S-Controller is in its PAUSE Slave Controller state. The entry “idle” in a cell of the above table indicates that, if a given S-module’s Slave Status register has its IIE and PIE bits set as in the two left-most columns of the given cell’s row, that S-module may source an interrupt when its S-Controller is in either its EOM or IDLE Slave Controller state.
I
The state of the PIE bit only has effect on S-modules that are addressed (but not uniquely) or not addressed. In the case of S-modules addressed by broadcast or multicast messages, thc P E bit’s having the value of logic 1 can be interpreted as pt-mitting infempts when the S-module’s S-Coiitroller is in its PAUSE Slave Controller state. However, in ; i n S.iiioti:ilc that is not addressed, the PIE and IIE bits together provide an encoding as indicated in table 10-1.
When an S-module has a pending interrupt, it asserts the MSD signal during every allowed Slave Controller state of its S-Controller until the intempt is serviced. If an sS-mbdule with a pending interrupt loses a Con- tend for Bus sequence, it will have the opportunity to generate an interrupt again (according to table 10-1 and accompanying note) when its S-Controller next enters one of the Slave Controller states in which inter- rupt generation is permitted according to the setting of the IIE and PIE bits.
During message transmission, if an S-module wishes to interrupt the M-module before the M-module begins the next packet transfer, that S-module has to assert the MSD signal no later than the rising edge of the MCLK signal occurring while the S-module’s S-Controller is in its xFER16 Slave Controller state. The sub- sequent falling edge of the MCLK signal is the last time that the M-module will be not be expecting to receive a packet bit from the S-module until the next (expected) packet pair transfer is completed.
10-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
IDLE . S-transferstates PAUSE : state
IEEE Std 1149.5-1995
S-transferstates PAUSE ' IDLE -
, - - 1 ICTL I
1st M-PACKET BITS 1-1 / EOM-00
state M:transfer states I PAWSE-01 I M:transfer states I PAUSE-01 I '1 IDLE-00
AMD [ T D F R - - - -
& -
Figure 10-14-module generated interrupt timing in relation to the signal on MCLK, Slave Controller states of an interrupting S-module's S-Controller,
and MTM-Bus message transfer
10-3
e'-
". .*
IEEE Std 11 49.5-1 995
11. S-module error response requirements
S-module error handling affects both MTh4-Bus Link Layer and MTM-Bus Message Layer resources, For clarity and simplicity, error handling related to both layers’ resources are presented together (as relevant) for each type of error treated by this Standard.
The type of errors treated are the following:
Self-Test Error Broadcast and Multicast Errors Data Overrun Error Parity Error State Sequence Error MSD Collision Error Data Transfer Port Error Command Sequence Error Illegal Command Error Packet Count Error Command Resource Unavailable Error
A variety of error conditions are reported b isters. When an error bit is set within the S Status register to be set in the S-module’s in the Bus Error reg bit of that S-module’s Slave St In addition, it is recommended S-module self-test (9.4.le). “hi Status register bit with the same (9.2.1h(ii)).
Once the BSE bit or the EVO bit of an S- indicate an interrupt
A discussion of recovery after an error at the levels of both packet and message are discussed in 13.2.
S-module’s Bus Error and Slave Status reg- register, this causes the BSE bit of the Slave
lg. Criteria for setting bits test will result in the MFS
of that register being cleared (1 1.2.1). be used to record the completion of an and BSY bits or some other S-module
Status register to be set
tatus register is set, the S-module is required to
11.1 S-module error respons nts
11.1.1 Specifications
(a) Any condition of an S-module fulfilling either of the following conditions shall be called an error:
(i) The condition causes the BSE bit of the Slave Status register to be set.
(ii) The condition causes the EVO bit of the Slave Status register to be set and is documented as an error in that S-module’s manufacturer’s documentation.
(b) For all errors, the manufacturer of an S-module shall provide documentation as to
(i) the nature of the error;
(ii) means of eliminating the error;
11-1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(iii) means (if any) of operating the S-module via the MTM-Bus while the error is not remedied.
(c) For each error type specified in clause 11 or by an S-module manufacturer’s documentation, the manufacturer of that S-module shall document
(i) the point(s) or period(s) with relation to S-Controller states/timing at/during which error detection occurs;
(ii) the maximum number of cycles of the signal on MCLK that may occur between the detection of an error and the S-module’s being capable of asserting an interrupt (10.1.1);
(iii) maximum interrupt latency (in number of packets) that may occur if the S-module is operated so that its S-Controller remains in its PAUSE Slave Controller state for exactly four cycles of the MCLK signal between packet transfers.
NOTES 1-With regard to Il.l.lc(i) it is sufficient to indicate an edge of d e MCLK signal since the following require- ments request maxima and are measured relative to the arbitrary time of detection. For example, it is convenient to consider the edge on which relevant values of MCTL ..REG and W - R E G are presented to an S-module’s S-Controller in the model of figure 7-3 as thc time of dctcction of a State Sequence Error (1 1.6.1).
2-1 1 . 1 . lc(ii) allows the designer of an MTM-Bus implementation to know what interrupts will occur while an S-module’s S-Controller is in its PAUSESlave Controller state following the transmission of a packet during or following which an error is detected. If the choice is made for packet transfer to proceed at such a rate that some interrupts cannot be asserted (or cannot be sure to be asserted) following transfer of the packet in which or following which those errors may be detected, lLl.lc(iii) provides that a designer will have the information necessary to predict latency of interrupts at the speed of operation required to be supported by all S-modules.
(d) When an S-module has detected an error during packet transmission and that error does not require at a given instant that the MSD signal be held at a constant logical value regardless of data that might otherwise have been transmitted, then
(i) any packet currently being transmitted shall, at the completion of its transmission, have good parity;
(ii) every subsequent packet within the current message shall be transmitted with good parity.
(e) For any S-module, any cln~l~-hiIi~rlliilg pnxxtiiire shall til.kc precedence over the defined message format of any currently excciitirig coiiiiiiaiid iiriless specificd otherwise in the S-module manufac- turer’s documentation.
(f) If more than one error is detected by an S-module and the relevant set of error-handling requirements conflict in terms of their effect on externally observable behavior of that S-module, then precedence with regard to final impact on external behavior of that S-module shall be as follows:
(i) Collision Error;
N O T W n c e a collision on the MSD signal is detected, the S-module detecting the collision cannot assert the MSD signal until the error handling for a Collision Error would permit the S-module to do so.
(ii) State Sequence Error;
NOTFGBarring the need to respond to a Collision Error, an S-module detecting a State Sequence Error cannot begin transmission of any sort of packet until allowed to do so by the error handling requirements for State Sequence Errors.
11-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(iii) unless specified otherwise in the detecting S-module’s manufacturer’s documentation, an error- handling procedure requiring the transmission of NULL packets for the remainder of the current message;
NOTE-Barring a requirement to hold the MSD signal at a constant logical value or S-module manufac- turer’s specifications to the contrary, the transmission of NULL packets has precedence over transmis- sion of non-NULL DATA packets.
(iv) unless specified otherwise in the detecting S-module’s manufacturer’s documentation, an error- handling procedure requiring transmission of DATA packets with the data contained in them fixed by the error-handling procedure rather than by the command executing when the error was detected.
Recommendations
(g) The manufacturer of any S-module that can be programmed to operate with fewer than four cycles of the MCLK signal between packet transfers within a message should document the consequences on interrupt latency of operating such an S-module in any such mode.
11.1.2 Description
All S-modules are required to be able to operate in a mode in which four cycles of the MCLK signal occur between transmission of packets in a given message. A manufacturer may supply whatever other flexibility may be deemed appropriate with regard to the number of cycles of the MCLK signal between packets. Implementation of the MPR signal in an S-module allows an S-module to signal a request for packet transfer to be delayed. The size of the inter-packet delays that might result can be estimated from the documentation required in 1l.l.la. Moreover, if an S-module offers enough flexibility so that it can be operated with fewer than 4 cycles of the MCLK signal between transfers of packets within a message, it is recommended that the consequences of such operation on interrupt latency be documented.
(a) In an S-module in which self-test is implemented, if a self-test reports detection of a fault, then, immediately following the completion of the self-test process, the S-module
(i) shall leave the MFS bit of the Slave Status register set;
(ii) shall clear the BSY bit of the Slave Status register.
NOTE-When the MFS bit of the Slave Status register is set and the BSY bit of that register is cleared, the EVO bit of the Slave Status register will be set (9.2.lh(ii); 9.4.le). This Standard recommends (9.4.le) that a Module Status register bit be used as an indicator of the S-module’s self-test failure.
Permissions
(b) Information concerning a self-test failure beyond that required by 11.1. l a may be recorded in a user- defined bit of an S-module status register (9.3 through 9.5).
11-3
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
11 -2.2 Description
When an S-module fails a self-test, diagnostic information may be available and be reflected in some S- module status register as defined by an S-module’s manufacturer’s documentation.
To know if a self-test passed, two indicators are needed-one for failure detection and one for self-test com- pletion. This is treated in 18.1.le and the accompanying note. If resetting of slave status registers is a good indicator of self-test completion (which would be the case if self-test were triggered by a command such as the Reset Module with SBIT command (18.2.1)), an S-module could be programmed to be in a non-zero multicast select group (9.2.1: table 9-3) prior to self-test. In such a case, if the multicast select group is 0 after the self-test surrenders control of the S-module, then the self-test has completed.
roadcast and multicast errors
Any S-module that receives the HEADER of a broadcast or multicast message without error will ensure that the BMR bit in that S-module’s Bus Error register is set at the completion of the message (9.3.1a; table 9-4). If one (or more) errors are detected by an S-module while receiving an HEADER packet, it is impossible to know if the S-module was to be addressed and, if so, what manner. In such a case, the BMR bit in the Bus Error register of the S-module will not be set (although it may remain set). Receipt ofa faulty HEADER
and accompanying notes). Settinglclearing the BMR bit is independent of the contents of the S- s registers. The BMR bit is only required to be valid at the conclusion of a broadcast or m
ipt of another, immediately follow- Bus Error Register can be affected
only by
- the presence or absence of ticast message: the execution of the command received
ER packet of the given mul-
of the given multicast message if and only if -
If it is desired to check the success o cast or multicast message. The BMR to the message of interest. If any S-m become addressed (possibly due to the d the BMR bit in that S-module’s Bus Error evant S-modules or by use of the Verify BMR command (16.12.1).
packet of a particular broad- and in the message just prior
e message of interest fails to transmission of the HEADER packet), s fact can be ascertained by polling rel-
A broadcast or multicast message that results in clearing of an S-module’s BMR bit may make determination of the success or failure of transmission of the HEADER packet of that message to that S-module impossi- ble. The BMR bit in such an S-module’s Bus Error register could be clear after the given message because of successful command execution or as the result of an error detected during receipt of the HEADER packet of that message.
11-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
11.4 S-module Data Overrun Error and response requirements
11.4.1 Specifications
(a) An S-module that is asserting the MPR signal, shall set the DOR bit in that S-module’s Bus Error register upon the S-module’s S-Controller’s entering its XFER16 Slave Controller state.
(b) If for any reason a given S-module that does not implement the MPR signal is not ready to participate in a packet pair transfer, that S-module shall set the DOR bit in the S-module’s Bus Error register upon the given S-module’s S-Controller’s entering its XFER16 Slave Controller state.
(c) Any response to a Data Overrun Error beyond those described in 11.4.la and 11.4.lb shall be as defined in the S-module manufacturer’s documentation.
Recommendations
(d) An S-module that detects a Data Overrun Error during a given message may transmit NULL packets during any future packet transfers that are part of the current message.
Permissions
(e) An S-module that detects a Data Overrun Error during a given message
(9
(ii)
may continue to participate in that message after taking the actions required by 11.4.la and 11.4.1b;
may cease to participate in any continuation of that message after taking the actions required by 11.4.la and 11.4.1 b and (subsequently) having its S-Controller enter its PAUSE Slave Con- troller state.
NOTE-The continuation of a message after occurrenc results.
a Data Overrun Error might produce unpredictable
11.4.2 Description
When the MPR signal is asserted, and S-module’s S-Controller enters its XFER16 Slave Controller state, the S-module will set the DOR bit in the Bus Error register. If a given S-module does not implement the MPR signal and is not ready to transfedreceive data when its S-Controller enters its XFER16 Slave Control- ler state, the S-module will set the DOR bit in the Bus Error register.
If an S-module is designed to continue participation in a message after a Data Overrun Error has been detected, the details of its operation in such circumstances have to be fully documented (22.1.1).
11.5 S-module Parity Error response requirements
11 5 1 Specifications
(a) An S-module that detects a Parity Error in an HEADER packet
11-5
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(i)
(ii) shall not become addressed.
shall not set or clear any bit in that S-module’s Bus Error register;
NQTE-Since an S-module detecting a Parity Error in an HEADER packet does not become addressed, it can- not discern the distinction between an attempt to address it uniquely or to address it in a multicast or broadcast message. Thus, the BMR bit of the S-module’s Bus Error register will not have its state affected by an HEADER packet with bad parity. If the BMR bit has not been cleared prior to the transmission of a broadcast or multicast message beginning with such an HEADER packet, the M-module cannot detect that the HEADER packet containing a Parity Error was received.
(b) An addressed S-module that detects a Parity Error in a packet other than an HEADER packet shall set the PRE bit in that S-module’s Bus Error register within one cycle of the MCLK signal following detection of the error.
NOTE--See 11.1.1~ for requirements on documentation of the time of detection of errors and the period (interrupt latency) between error detection and the detecting S-module’s first raising an interrupt.
(c) Subsequent to detection by a given S-module of an error described in 11.5.lb and during the same message in which such detection took place, the default error response action for an S-module shall include its continued participation in the current message.
NQTE--eontinuation of the message is required in the case of a Data Echo Test message (16.11.1).
(d) Any response to a Parity Error beyond those described in 11.5.1a, l lS . lb , and 11.5.1~ shall be as defined in the S-module manufacturer’s documentation.
11.5.2 Description
An HEADER packet having incorrect parity will not cause any error to be set or cause an interrupt to be signaled, and an S-module recognizing the Parity Error in an HEADER packet will not become addressed. This will prevent an excessive number of interrupts from k i n g signaled due to single-bit errors on the MCTL or the MMD signal. The M-module will detect errors by the lack of an expected S-module response. When a Parity Error is encountered in an HEADER packet, an ule intended to be uniquely addressed will not transmit an ACKNOWLEDGE packet. Therefore, it i cause the Acknowledge Request bit in the HEADER packet of such a message to be set to verify that the correct S-module has received the HEADER packet without error.
If an S-module is designed to do anything other than continue normal participation in a message after a Par- ity Error has been detected in a packet other than an HEADER packet, the details of its operation in such cir- cumstances have to be fully documented (22.1. Id).
11.6 S-module State Sequence Error response requirements
11.6.1 Specifications
(a) An S-module that detects a State Sequence Error (7.1.1; figure 7-1) when not addressed
(i) shall not become addressed;
(ii) shall not set or clear any bit in that S-module’s Bus Error register;
11-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(iii) shall take no additional action in response to the detected State Sequence Error beyond that pre-
NOTES 1-The process of detecting a State Sequence Error involves the S-Controller’s transition to its ERROR Slave Controller state (figure 7-1).
2 4 i n c e an S-module detecting a State Sequence Error during transmission of an HEADER packet does not become addressed, it cannot discern the distinction between an attempt to address it uniquely or to address it in a multicast or broadcast message. Thus, the BMR bit of the S-module’s Bus Error register will not have its state affected by the State Sequence Error. If the BMR bit has not been cleared prior to the transmission of a broadcast or multicast message in which a State Sequence Error occurs during transmission of the HEADER packet, the M-module cannot detect that the HEADER packet containing a State Sequence Error was received.
scribed in 7.1.1 and figure 7-1.
(b) A uniquely addressed S-module that detects a State Sequence Error (7.1.1; figure 7-1) during trans- mission of a packet
(i) shall set the SSE bit in that S-module’s Bus Error register upon that S-module’s S-Controller’s entry into its ERROR Slave Controller state (7.1, figure 7-1);
(ii) shall assert the MSD signal on the next rising edge of the MCLK signal;
(iii) shall not release the MSD signal so long as the given S-module’s S-Controller remains in its ERROR Slave Controller state;
(iv) shall release the MSD signal on the first rising edge of the MCLK signal after the given S- module’s S-Controller enters its IDLE Slave Controller state-unless the specifications of 10.1.1 require the MSD signal be asserted at that time.
NOTES 1-The process of detecting a State Sequence Error involves the S-Controller’s transition to its ERROR Slave Controller state (figure 7-1).
2-A uniquely addressed S-module is required to assert the MSD signal upon the entry of that S-modules’s S- Controller into its ERROR Slave Controller state. When an S-Controller has entered its ERROR Slave Con- troller state, the S-module containing that S-Controll be assumed to be tracking MTM-Bus activity and cannot predict when the S-Controllcr would bc ex be in a particular Slave Controller state. Hence, the S-module cannot be selective with rcgard lo timing of assertion of the MSD signal to create an intempt. If an S-module always asserts the MSD signal while in its S-Controllers’ ERROR Slave Controller state, the M- module can detect an interrupt at the earliest possible time. Once the S-module’s S-Controller makes the tran- sition from its ERROR Slave Controller state to its IDLE Slave Controller state, the s-module is resynchronized with the M-module and interrupt control reverts to control by the states of the PIE and IIE bits of the S-module’s Slave Status register.
(c) When addressed by a broadcast or multicast message, an S-module that detects a State Sequence Error (7.1.1, figure 7-1) during transmission of a packet
(i) shall set the SSE bit in that S-module’s Bus Error register upon that S-module’s S-Controller’s entry into its ERROR Slave Controller state (7.1, figure 7-1);
(ii) shall release the MSD signal on the next rising edge of the MCLK signal after the State Sequence Error is detected;
(iii) shall not assert the MSD signal so long as the given S-module’s S-Controller remains in its ERROR Slave Controller state.
11-7
IEEE Std 11 49.5-1995 IEEE STANDARD FOR MODULE TEST AND
NOTES
I-The process of detecting a State Sequence J3-m involves the SController’s transition to its ERROR Slave Controller state (figure 7-1). 2- Once the S-module’s S-Controller makes the transition from its ERROR Slave Controller state to its IDLE Slave Controller state, the S-mcdule is resynchronized with the M-module and interrupt control reverts to control by the states of the PIE and IIE bits of the S-module’s SIave Status register as defined in table 10-1.
3-Behavior as to assertion or release of MSD when a State Sequence Error is detected during a broadcast or multicast message is consistent with the specification that an S-module may not assert MSD in response to broadcast or multicast messages except those containing in their HEADER packets the command codes for the Contend for Bus or Verify BMR (8.2.la). In the cases of the Contend for Bus and Verify BMR commands, it would be counterproductive to disturb the operation of the command by having an S-module detecting an State Sequence Error win the contend (as might happen) even if it had not previously sourced an interrupt,
+When an S-module that is contending for the MTM-Bus detects an SSE during the contend sequence, there are two possibilities: (1) If all S-modules currently participating in the contend sequence detect the State Sequence Error, then the M-module will receive an apparent Slave Status register content with no bit set to logic ‘I.’ This indicates the presence of an error because at least one bit of an S-module’s Slave Status register has to have been set in order for that S-module to have been participating in a contend sequence. (2) If one or more S-modules that are currently participating in the contend sequence do not detect the State Sequence Error (suggesting that whatever error was detected is actually internal to the detecting module), the contend sequence will continue normally; and the S-module detecting the State Sequence Error will now signal an interrupt again as soon as its programming allows.
is detected will not cause an S-mod- g the State Sequence from being signaled
ADER errors by the lack of an expected S-module response.
chowledge Request bit in the HEADER packet of a message intended to be address
In the case of a State Sequence Error detected during transmission of packets other than an HEADER packet, an uniquely addressed S-module will assert the MSD signal upon detection of the error. Whether or not an S-module is uniquely addressed, it e error so that an interrupt not ser- viced while the S-module’s S-Controller er state can be signaled again at a later time if necessary.
11.7 MSD signal collision response requirements
11.7.1 Specifications
(a) Except when an S-module is returning the ACKNOWLEDGE packet in response to the Verify BMR (16.12.1) and Contend for Bus (16.4.1) commands, when an addressed S-module detects a collision on the MSD signal (4.3.la; 4.3.lb; figure 4-1) while the S-module’s S-Controller is in one of its S- transfer states as a consequence of M-module signals transmitted on a rising edge of the MCLK signal at time t, the S-module
(i) shall set the SDF bit in its Bus Error register wifiin one cycle of the MCLK signal following t;
(ii) shall not assert the MSD signal during the current message following time t except while the S- module’s S-Controller is in a Slave Controller state in which an interrupt may be signaled
11-8
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
according to the programming of the S-module, 10.1.1, and table 10-1 and its accompanying note.
NOTES 1-MSD signal collision occurs when two S-module’s both operate as though they were uniquely addressed.
2-This error-handling procedure will prevent the situation in which a message might continue with some packets being transmitted by one S-module, but others transmitted by a different S-module.
3-When the S-module is permitted to generate an interrupt it will be required to do so because of the SDF bit’s being set in the S-module’s Bus Error register.
11.7.2 Description
Each S-module is required to contain signal collision detection logic for the MSD signal (4.3.1). The report- ing of a detected collision has to be enabled for all data transfers by the S-module except when returning the ACKNOWLEDGE packet in response to the Contend for Bus or the Verify BMR command.
11.8 S-module Data Transfer Port Error response requirements
11.8.1 Specifications
&&s
(a) When an addressed S-module detects that an unsupported logical Port IdenLiier (clause 2 selected for a Data Transfer class command (clause 17), the S-module
(i) shall set the IPS bit of its Bus Error register;
) was
(ii) shall transmit NULL packets during all packet transfers for the remainder (if any) of the current message.
(b) When an addressed S-module detects that a port currently selected (17.1.1 a) by a Data Transfer class message has reported an error, the S-module shall set the PTE bit of its Bus Error register.
(c) Except in the case of a Read Status message during which an S-module has to transmit one or more packets than it has status registers (16.1.1d), when both
(i) an addressed S-module is required by a currently executing command to begin transmitting a DATApacket the next time the S-module’s S-Controller is in its xFERl6 Slave Controller state and
(ii) for any reason other than the occurrence of a Data Overrun Error (1 1.4. l), the intended contents of this DATA packet cannot be accessed,
the S-module shall set the PTE bit of the Bus Error register within one cycle of the MCLK signal of detecting the error.
(d) Subsequent to detection by a given S-module of an error described in 11.8.lb or 11.8.1~ and during the same message in which such detection took place, the default error response action for an S- module shall include its continued participation in the current message.
11-9
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(e) When an addressed S-module detects that a port currently selected (17.1. la) by a Data Transfer class message is inaccessible for any reason, the S-module shall set the ETE bit of the Bus Error register within one cycle of the MCLK signal of detecting the error.
(0 In any addressed S-module, when a port currently selected (17.1.1a) by a Data Transfer class message does not support the command of which the command code was transmitted in the HEADER packet of the current message, the S-module shall set the PTE bit of the Bus Error register within one cycle of the MCLK signal of detecting the error.
(8) When
(i) a selected port on an addressed S-module ceases to be selected due to termination of the current message (17.1.1b) and
(ii) that port never received the complete set of DATApackets required by the port-specific portion of the format of the currently executing command,
the S-module shall set the PTE bit of the Bus Error register within one cycle of the MCLK signal of detecting the error.
(h) Any response to Data Transfer Port Errors beyond those described in ll.S.la, 11.8.1b, 11.8.1c, and 11.8. Id shall be as defined in the S-moduIe manufacturer’s documentation.
11.8.2 Description
The S-module will detect an Jl1e”gal Selected Error afterreceiving the PORT ID packet within a Data Transfer class message if the Porl Id cr co~~liii~~ecl in that packet is not supported. See table 21-1 for the list of reserved Port Identifiers. Errors rcporlcd by ii currently selected port or the inability to access data intended to be transmitted by thc S-module arc reasons for setLkg €he PTE bit of an S-module’s Bus Error register. While the default action for an S-iiicxlule dcledng an error of the type described in 11.8.lb and 11.8.1~ is to continue transmitling 1)A‘l’A piickct% to thc M-module, other responses (including the transmis- sion of NULL packets instead of cxpcctcd DA’l’A packets) as long as they are fully docu- mented by the S-module’s manufacturer.
(a) When an S-module is addressed by an Enable Module Control (EMC) message (1 6.10.1) and does not receive a command requiring the EMC command in the first HEADER packet following receipt of the EMC command (table 15-1) or is not addressed in the first HEADER packet following receipt of the EMC command, the S-module
(i) Shall set the CSE bit in its Bus Error register;
(ii) Shall execute the command conveyed by the HEADER packet that caused the Command Sequence Error if addressed in that HEADER packet.
NOTES
1-In case an S-module is addressed in a HEADER packet that causes a Command Sequence Error, the S- module will execute the command the command code of which appears in the Command field of that HEADER
11-10
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
packet. This is required on the assumption that there may be a system critical reason for intempting the expected command sequence.
2-According to 16.10.lc, an S-module has to delete its record of having received an EMC command if the next HEADER packet that S-module receives is faulty (i.e., generates a Parity Error or a State Sequence Error).
(b) When an S-module receives a command that has to be preceded by the EMC command (table 15-1; 16.10.1) and did not receive an EMC command in the HEADER packet of the preceding message, the S-module
(i) shall set the CSE bit in its Bus Error register;
(ii) shall not execute the current command.
(c) If a given S-module detects a Command Sequence Error as defined in 11.9.la and 11.9.lb and the Acknowledge Request bit was set in the most recently received HEADER packet, the detecting S- module shall transmit an ACKNOWLEDGE packet as required (14.1 .lb).
(d) If a given S-module detects a Command Sequence Error as defined in 11.9.la and 11.9.lb, then with the exception of an ACKNOWLEDGE packet transmitted under the conditions specified in 11.9.1c, the S-module shall transmit only NULL packets during all packet transfers for the remainder (if any) of the current message.
(e) If an S-module implements permission 16.10.ld, then the time-out causing the record of an EMC message to be deleted shall also cause the CSE bit of the S-module’s Bus Error register to be set.
11.9.2 Description
A Command Sequence Error wilI be detected while the detecting S-module’s S-Controller is in its PAUSE Slave Controller state immediately following an HEADER packet transfer.
11.10 S-module Illegal Command E
11.10.1 Specifications
e requirements
When an addressed S-module receives an HEADER packet containing the command code of an unimplemented command (15.1; table 15-1; 20.1.1; 20.2.1), aReserved command (15.1; table 15-1; 16.16.1; 17.5.1; 18.5.1; 19.10.1), or the Illegal command (16.17.1), the S-module shall set the ILC bit of its Bus Error register.
If a given S-module detects an Illegal Command Error as defined in 11.10.la and the Acknowledge Request bit was set in the erronems HEADER packet, the detecting S-module shall transmit an ACKNOWLEDGE packet as required (14.1. lb).
If a given S-module detects an Illegal Command Error as defined in 11.10. la, then with the exception of an ACKNOWLEDGE packet transmitted under the conditions specified in 11.10.lb, the S - module shall transmit only NULL packets during all packet transfers for the remainder (if any) of the current message.
11-11
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
11.10.2 Description
An Illegal Command Error will be detected while the detecting S-module’s S-Controller is in its PAUSE Slave Controller state following the transfer of the HEADER packet containing the command code in ques- tion.
The Illegal command provides a metbod for the S-module to detect a stuck-at-one condition on the MTM- Bus (16.17.2).
Detecting reserved and unimplemented command codes provides a method for testing validity of S-module command code interpretation.
(a) When an S-module that implements packet counting (14.2.1) detects a Packet Count Error (9.3.1; figure 9-4), then the S-module
(i) shall set the IPC bit in ils Bus Error rcgiskr;
(ii) shall continue participatiori as dcfiiictl irr the S-iiitdluic niaiiufacturer’s documentation in any message that may still bc corrtm~.
NOTE-When unexpectedly few pirckcts arc: lraiisfcrr‘cd as p r i ol’ ii 1 rick:igc following successful transmis- sion of the PACKET COUNT pickel of LlIiiI I I I C S S ~ I ~ C , dic S-iirodulz ciiii only determine this is the case after the completion of the illcssagc or by tlctcction ol’a Shtc Srx;iizirc:c Error. €a either case, an S-module detecting the Packet Count Error will scl thc Il’C hit in ils Bus Ikror Rcgistol: It! the last case, the SSE bit in the Bus Error register will also be sei ( I I h . 1 ) . A Shie Scqucncc E~NII. rxxurring during transmission of the PACKET COUNTpacket will result i l l only tlm SSH hii’s king xt.
(b) An S-module shall sct thc I i T bit of thc S-morlulc’s h i s 1k-w rcgister when the S-module’s S-Con- sage consisting only of transmission of troller enters its IDLE Slave Controller state follow&
a HEADER packet addressing the S-rnodule:and, in addition, either of the following occurs:
(i) The S-module in question iinplcmcnts packet counling (142.1); and, in the given HEADER packet, the Acknowledge Requcst hi1 is set; arid Ilic command code of the Data Echo Test command (16.11.1) is not conlniiicd io the givcri IlE~!IUB# packet’s Command field.
(ii) In the given HEADER packet, the Command field contains the command code for the Contend for Bus (16.4.1) or Verify BMR (16.12.1) command.
11.11.2 Description
An Incorrect Packet Count Error (14.2.1) will occur if an S-module detects that the number of packets trans- ferred in a message is not equal to the number of packets specified in the PACKET COUNT packet of that message.
In cases in which a PACKET COUNT packet transfer is expected in a message, but that message terminates immediately after the HEADER packet, this will be considered an Incorrect Packet Count Error (the IPC bit of the S-module’s Bus Error register will be set).
Interruption of transmission of a PACKET COUNT packet by a State Sequence Error will cause the SSE bit of addressed slaves Bus Error registers to be set. In this case, the IPC bit of those registers will not be set.
If an S-module is addressed in a given HEADER packet containing the command code for a command C and a resource required to complete execution of C is unavailable at the time the HEADER packet is received or (in the case that C is a Data Transfer class command (15.1.1; table 15-1; clause 17) such a resource is not available at the time the PORT ID packet (17.1.1a) of the current message is received, that S-module
(i) shall set the CRU bit in its Bus Error register;
(ii) shall not execute C.
If an S-module is addressed in an HEADER packet containing the command code of a non-Core class command and the BSY bit in that S-modules’s Slave Status register is set,
(i) the S-module shall set the CRU bit in its Bus Error register;
(ii) the command shall not be executed.
NOTES 1-The BSY bit of the Slave Status register indicates whether an S-module is currently executing an MTM-Bus command or module start-up sequence that may include a self-test procedure (9.2.1; table 9-1).
2-Core class commands are always executed despite the state of the BSY bit.
If a given S-module detects a Command Resource Unavailable Error as defined in 11.12.la and 11.12.lb and, in addition, the Acknowledge Request bit was set in the erroneous HEADER packet, the detecting S-module shall transmit an ACKNOWLEDGE packet as required (14.1.1b).
If a given S-module detects a Command Resource Unavailable Error as defined in 11.12.la and 11.12.lb, then with the exception of an ACKNOWLEDGE packet transmitted under the conditions specified in 11.12. IC, the S-module shall transmit only NULL packets during all packet transfers for the remainder (if any) of the current message.
11.12.2 Description
The CRU bit is used to indicate that a resource required to complete execution of a command was not avail- able at the time when the command was received. A specific case of this occurs when the BSY bit is set because the module is presently executing a command, and an HEADER packet is received containing the command code for a non-Core class command -the command cannot be executed when the BSY bit is set. For requirements regarding timing of the setting of an error bit, see 1 1.1.1.
11-13
IEEE Std 1149.5-1995
12. MTM-Bus Message Layer: General requirements
12.1 MTM-Bus Message Layer general requirements
12.1.1 Specifications
(a) An MTM-Bus message shall consist of the transfer of one or more packets.
(b) The number and type of packets transferred in a given message shall be determined by requirements of the command code contained in the Command field of the HEADER packet (5.2.1) of that message.
NOTE-Requirements covering commands and their command codes are to be found in clauses 15-20.
(c) MTM-Bus singlecast messages shall consist of the following packet types in the given order and transmitted by the M-module or an S-module according to figure 12-1:
(i) one HEADER packet (5.2.1);
(ii) zero or one PACKET COUNT/ACKNOWLEDGE packet pair (5.2.ld; 5.3.1; 5.4.1; 13.1.1);
(iii) zero or more DATApacket pairs (5.2.ld; 5.5.1; 5.6.1).
NOTES
1-The tern “packet pair” describes the two packets (one sent by the M-module and one by an S-module) sat- isfying the condition that the transmission of the last 15 bits of the M-module-originated packet are transmitted simultaneously with the first 15 bits of the S-module originated packet.
2-The operation of the M-module with regard to transmission of PACKET COUNT packets is covered in 13.1.1.
(d) MThl-Bus broadcast and multicast messagcs arhc an those containing the command code of the Contend for Bus (16.4.1) or Verify BMR (16.12.1) command shall consist solely of M-module trans- mission of the following packet types in the given order:
(i) one HEADER packet (5.2.1);
(ii) zero or one PACKET COUNT packet (5.3.1, 13.1.1);
(iii) zero or more DATApackets (5.5.1,5.6.1).
NOTES 1-Broadcast or multicast Contend for Bus (16.4.1) and Verify BMR (16.12.1) commands are special Cases. In any other broadcast or multicast message, an addressed S-module is forbidden to transmit packets (8.2.la).
2-The operation of the M-module with regard to transmission of PACKET COUNT packets is covered in 13.1.1.
(e) When an M-module or an uniquely addressed S-module is not required to transmit data in the half of a DATA packet pair that it originates, that module shall transmit a NULL packet (5.6.1) as the packet it originates in the given DATA PACKET pair.
NOTELIf data are expected to be transmitted in only one direction during a message (say from M-module to S-module), then the packets transmitted in the opposite direction (in the example, from S-module to M-
12-1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
module) will be NULL packets. In a message in which data are transmitted by both M-module and S-module, if the M-module has no more data to send but expects more data from the S-module, the M-module will begin transmitting NULL data packets as the M-module's half of the DATA packet pairs required by 12.1.1c(iii) and continue to do so until all data from the S-module are received. The example also holds when the roles of the M-module and S-module are reversed.
When an S-module is addressed by a multicast or broadcast message, any processes that would occur within the S-module had the message been singlecast [other than those unnecessary because of the S-module's being forbidden to transmit data (8.2.la; 12.l.ld)l shall occur without any alteration in action or effect.
NOTE-If in a multicast or broadcast message an S-module receives a command that would cause destructive reading of a register or memory had the command been conveyed in a singlecast message, the target data will be lost without the M-module having the advantage of receiving it. Also, an S-module will not be transmitting anything during such a message with the exceptions permitted by 8.2.la and 12.1.ld.
12.1.2 Description
An MTM-Bus message consists of one or more 17-bit packets (clause 5) being transmitted between the M- module and one or more S-modules. The types of packets transmitted 011 the bus include HEADER packets, ACKNOWLEDGE packers, PACKET COUNT pacbts, NULL packets and non-NULL DATA packets. Fig- ure 12-1 depicts the four allowablc h?TT1\Mhis niesmge scqiicnccs. A s dcpicted. caeh message begins with a HEADER packet being sent frorr: thc M-niodiilc io all S-ii~orluics. Ilris I-IT;.Al>ER packet identifies the S- module(s) to participate in the mcssngc (via ail trdtirss ticld) and i i i ) intliculioii of the message type (via a command field). The HEADER pucket format is dcscribcrl in 5.2.
An ACKNOWLEDGE packet c;m bc reqiicstetl from an ; d ( h ~ ~ ~ i i S-iiiodulc by setting the Acknowledge Request bit in a HEADER packet (5.2). A!] ACKNOWLEDGE packzt returncc1 by an S-module will contain the address of that module and the contents o f illat inodule's Slavc Status rcgistcr. The ACKNOWLEDGE packet is intended to be a bus transfer i ~ c k n o ~ l e d g i ~ ~ ~ t , iridicating that an S-module has received the imme- diately preceding HEADER packcl wil houl crror and informing thc M-module of which S-module is responding. The Slave Status dah conlaincd in an ACKN0WLdH1)GE jxickct di)Js not reflect changes to the addressed S-module's Slave Status rrgiuter' that will ~ x c u r as a result of r'ctxipt of the HEADER packet in which the ACKNOWLEDGE packcl W ~ I S r ~ ~ l l l ~ s k d (S.3; 9.2).
Note that the Acknowledge Request bit is extraneous% the cases of the Contend for Bus (16.4.1), Verify BMR (16.12.1), and Data EchoTest (16.11.1) commands.
The Contend for Bus and Verify BMR r~oriin~iiii~ls j)r(wbce ii Icspor1w I'roin both uniquely addressed S-mod- ules and those addressed by broadcast or rnullicast. For all othcr b1r)ildcitst or multicast commands defined in this Standard, the Acknowledge Request bit informs the addressed S-modules that the M-module will send a PACKET COUNT packet immediately following the HEADER packet in the current message (12.1.1c(ii); 13.1.1). However, no ACKNOWLEDGE packet can be returned in this case (8.2.la).
A PACKET COUNT packet will be transmitted by the M-module to an uniquely addressed S-module and to broadcast or multicast addressed S-modules in the case of the Read Status (16.1.1), Contend for Bus (16.4,1), and Verify BMR (16.12.1) commands when the S-module is transmitting a requested ACKNOWL- EDGE packet (5.3). A PACKET COUNT packet is transmitted only if the Acknowledge Request bit in the immediately preceding HEADER packet (5.2) was set or if the command codes of one of the three cited commands occurs in that HEADER packet (13.1.1). The PACKET COUNT packet identifies the number of packet transfers that the M-module will perform in the current message following the PACKET COUNT packet. If the number of packets remaining to be transferred is unknown or unspecified or if packet counting (14.2.1) is not supported by the S-module in question or at the discretion of the application controlling the M-module, a PACKET COUNT packet with all zeros in the Packet Count field may be sent. If such a PACKET COUNT packet is sent to an S-module that supports packet counting, it will operate in degraded mode (14.2.1(ix)).
12-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
a
b
Packets Sent by M-module Packets Sent by S-module
I HEADER I ------+
I HEADER ____)
I PACKETCOUNT I e
C I PACKETCOUNT 1
11 st M-module DATA 1
I2nd M-module DATA
ACKNOWLEDGE
I ACKNOWLEDGE I
I2nd S-module DATA]
1 1 st M-module DATA 1
I HEADER I
12nd M-module DATA1 12nd S-module DATA1
IEEE Std 1149.5-1995
NOTE-Messages of types a and b are called *simple messages.
NOTE-Messages may consist of a single HEADER packet or include transfer of ACKNOWLEDGUPACKET COUNT and DATA packets. Messages with message sequence of types a and b are called simple messages. Only two DATA packet pairs are illustrated for formats c and d; however, there is no limit to the number of DATA packets that can be sent in an MTM-Bus message.
Figure 12-1-Packet transfers defining the MTM-Bus message sequences
(a) The M-module shall transmit a PACKET COUNT packet (5.4.1) as the first packet following an HEADER PACKET (5.2.1) of which either of the following is true:
(i) The Acknowledge Request bit (5.2.ld) in the given HEADER packet was set and the command code of the Data Echo Test command (16.11.1) does not appear in the Command field of the given HEADER packet;
(ii) The Read Status (16.1.1), Contend for Bus (16.4.1)’ or the Verify BMR (16.12.1) command code is contained in the HEADER packet’s Command field.
NOTE-When a PACKET COUNT packet is transmitted in accord with the conditions of 13.1.1a(ii), there is no change in the meaning of that packet’s contents as compared to any other command.
@) The M-module shall not transmit a PACKET COUNT packet (5.4.1) at any time other than those specified in 13.1.la.
(c) If an M-module is reqbired to transmit a PACKET COUNT packet because 13.1.1a(ii) holds while 13.1.1a(i) does not hold, t l p the packet count transmitted shall be zero.
NOTE-Any packet transmitted after a PACKET COUNT packet is considered a DATA packet although, to some selected port, the contents of the packet may be interpretable as a packet count.
13.1.2 Description
Following an HEADER packet transfer, the M-module will d a PACKET COUNT packet to an addressed S-module if the S-module is expected to return iiw ACKNOWLEDGE packet. With the exception of the cases listed in 13.1.1a(ii), if the HEADER packet does not have its Acknowledge Request bit set, a PACKET COUNT packet will not be transferred.
Although the M-module has to send a PACKET COUNT packet if the conditions of 13.1.la apply, no S- module is required to use this information.
13.2 Post-error recovery at packet and message levels
If an M-Module detects an interrupt during a message, we may assume there is some type of M-module response necessary or desirable. This response can include an impact on the current message (i.e., continue transfer vs. terminate transfer), diagnostic efforts, and message retransmission. M-module response is very dependent on system requirements and is not defined in this document.
After an interrupt received during a message, the M-module or an application controlling the M-module first has to determine whether to continue or to terminate the message. That decision may be influenced by the following:
- Interrupt soume-If only one S-module is addressed and if the PIE bit has been cleared in the Slave Status registers of all S-modules, then the interrupt can only be coming from the addressed
13-1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
S-module. In such a case a decision is requid as to whether the message should continue or stop immediately (for error containment purposes). If more than one S-module could be sourcing the interrupt, then the same choice would have to be made even though the interrupt may not be being sourced by the S-module(s) receiving the message.
- Message importance-If it is very important that the data being transferred be received without error or that the application controlling the M-module has to be signaled immediately if a data transfer failed (e.g., in the case of an initial program load), then the appropriate action may be to terminate the message.
- Interrupt latency-This is the length of time that passes between an interrupt’s being signaled by an S-module and the interrupt’s being serviced (i.e., error condition cleared in the interrupting S-mod- ule). If transfer of a long message is to continue after an interrupt is detected by the M-module, there may be a significant amount of time before the intempt is serviced, which may cause other errors. If the message involved is very short, it may not matter whether the message is terminated or not.
After a message is terminated the application controlling the M-module may be required
- to identify the source or type of interrupt [possibly by using the Contend for Bus (16.4.1) or Verify BMR (16.12.1) command] and/or cause additional testing to occur [e.g., by use of the Data Echo Test command (16.11.1)];
- to reactivate message transmission.
When message transmission continues after an interrupt, there are at least two options:
- Message recovery-The M-Module retransmits the message as initially transmitted. This could take a significant amount of time if the message was a data transfer containing many packets.
- Packet recovery-The M-module retransmits the message startiug at some point prior to the point at which the interrupt provoking error occurred. This method requires the M-module or the application controlling it to be able to determine out the 1a.t M-module originated packet that was transferred correctly.
13-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
14. MTM-Bus Message Layer: S-module requirements
14.1 S-module general HEADER packet decode and general command response requirements
14.1.1 Specifications
(a) An S-module shall decode each HEADER packet (5.2.1) received without error-to determine if that S-module is addressed (3.3.1).
NOTE--No S-module can become addressed as a result of receiving a HEADER packet during which an error was detected (e.g., bad parity in the HEADER packet in question or a State Sequence Error). See 3.3.ld.
(b) If the Acknowledge Request bit is asserted in the HEADER packet (5.2.1) of a singlecast message, then the addressed S-module shall respond with an ACKNOWLEDGE packet (5.3.1) during the next packet transfer unless the command code of the Data Echo Test command (16.1 1.1) appears in the given HEADER packet’s Command fiefd.
(c) Once an S-module is uniquely addressed and after an ACKNOWLEDGE packet has been trans- mitted if requested, an uniquely addressed S-module shall transmit DATA packets or NULL packets required by the decoded command in the manner specified in the command definition.
NOTES 1-The M-module will be expecting a DATA packet or a NULL packet from an uniquely addressed S-module corresponding to every DATA packet or NULL packet transmitted by the M-module (12.1.1~; 12.1.le). Command codes are defined in clauses 15-20.
2-As specified in 8.2.la, S-modules cannot transmit packets in response to Multicast or Broadcast commands except in response to the Contend for Bus (16.4.1) and Verify BMR (16.12.1) commands.
(d) If an S-module receives a HEADER packet containing in its Command field the command code of the command, C, and the BSY bit in that S-module’s Slave Status register is clear, then the S-module shall execute C.
NOTE-Error handling in case the BSY bit is set when a HEADER packet is received is specified in 11.12.lb.
(e) An S-module shall execute Core class commands (15.1; clause 16) regardless of the state of the BSY bit within that S-module’s Slave Status register.
NOTES
I-Core class commands (table 15-1) are executed whether or not the BSY bit is set in an S-module’s Slave Status register. Since no command can be transmitted without starting a new message, the only commands that might be executing when a Core class command is received are those whose execution takes place after a message terminates. 2-An S-module’s application logic may need to be aware of activity in that S-module’s MTM-Bus interface logic.
( f ) For any command the message format (F) of which consists entirely of transfer of a HEADER packet, the execution of that command in an S-module addressed by a message with the F format shall occur as follows:
(i) if such a message is broadcast or multicast, the setting of the BMR bit in any addressed S- module’s Bus Error register shall occur prior to execution of the command;
14-1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(ii) the command execution shall begin while an addressed S-module’s S-Controller is in its EOM Slave Controller state and before any subsequent message transmission can begin.
NOTES
1-As a consequence of this rule, those simple commands (12.1.1; figure 12-1) that cause a reset of an S- module’s Bus Error register (9.3.1) will clear the BP/LR bit of that register in cases in which the command is conveyed by a broadcast or multicast messagedespite successful transmission of the HEADER packet of the message. G
2-The setting of the BMR bit (9.3.1; figure 9-4) by commands not covered by 14.1. If is specified within the definition of such commands (where required) (22.1.lf). The time (period) of execution of commands not covered by 14.1. If is required to be documented (22.1. If) by an S-module’s manufacturer.
14.1.2 Description
If the Acknowledge Request bit is set in a HEADER packet, a uniquely addressed S-mod an ACKNOWLEDGE packet during the next packet transfer period as shown in ACKNOWLEDGE packet transmitted does not include status changes due to contents of the HEADER packet in which the Acknowledge Request bit was set.
Following transmission of an ACKNOWLEDGE p’ el, ;I unic~~idy arltlrcqed S-module will transmit DATA packets as required by the comm:ind reccivcd in thc I111AIZ15R pxket (figure 15-1). S-module responses to MTM-Bus commands are dcscribcc! in C ~ ~ N I S C S 16-20.
- .- I --. _ _ i fd-module xrnittcd bits ! I___ - - MMD
- xmitted bits - MSD
NOTE-Full-duplex transmission of DATA packots is siipporlod on conrnnr;ds :hat rcqiiirc it as shown in these final pack- ets of a data transfer message. Note the delay of two cycles of Ihe MCLK signal between start of an M-module packet transmission and start of the linked S-module packet transmission.
Figure 14-1-Full-duplex data transmission
14.2 S-module packet-counting requirements
14.2.1 Specifications
(a) In order for any S-module to be said to “implement packet counting” (14.2.lb):
(i) The manufacturer of the S-module shall document the S-module as implementing packet counting.
14-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.9-1 995
(ii) The S-module shall extract the data from the Packet Count field of each PACKET COUNT packet received.
(iii) Subsequent to the required action of 14.2.1a(ii), the S-module shall treat the extracteo data value as the packet count of the current message if that data value is greater than 0.
(iv) The S-module shall implement a function that counts the number of packets received during each message excluding the HEADER and PACKET COUNT packets.
(v) Throughout any message that contains a PACKET COUNT packet containing a nonZen count, the S-module shall compare the number of packets received during that mess lowing the PACKET COUNT packet to the packet count of the current message.
(vi) The S-module shall recognize as a Packet Count Error the case in which the number of of a message following a PACKET COUNT has exceeded the packet count of the mes
NOTE-Packet Count Error handling is treated in 11.1 1.1.
(vii)The S-module shall recognize as a Packet Count Error the case in which a message ter with the number of packets trans-dtted after the PACKET COUNT packet of the mess than the packet count of the message.
NOTE--Packet Count Error handling is treated in 11.11.1.
(viii)The S-module shall behave as though it failed to satisfy the requirements defined in 14 through 14.2.1(viii) when the data value in a received PACKET COUNT packet is 0.
Recommendations
(b) An S-module should implement the capability called packct counting (14.2.la).
14.2.2 Description
In cases in which the number of DATA packets to be transmitted by an M-module are known in a1 packet counting provides an additional check on the sanity of MTM-Bus operation.
If a PACKET COUNT packet transmission is interrupted, this will be detected by a State Sequenc having occurred, not via packet counting.
14.3 Summary of S-module message sequence requirements
The MTM-Bus Slave message sequence is shown in figures 14-2 through 14-4.
)acket :e fol-
ackets
inates ;e less
!.la(i)
rance,
Error
In these figures, the following types of errors can be distinguished
- Header Errors - CommandErrors - Data Packet Errors (Qpes 1 and 2) - Data Overrun Errors - Post-Message Errors
HEADER Errors-Header Errors are those that are detected when the S-module is expecting to redeive a HEADER packet. Two potential errors may occur:
14-3
IEEE Std 1149.5-1995 fEEE STANDARD FOR MODULE TEST AND
- A HEADER packet is received that is not 17 bits in length (i.e., a State Sequence Error). - The packet parity is incorrect (i.e., a Parity Error).
An S-module’s response to a Header Error is to wait for its S-Controller to be in its IDLE Slave Controller state as detailed in 11.5.la and 11.6.la. When a Header Error is encountered, the S-module does not become addressed and, hence, will not transfer an ACKNOWLEDGE packet.
Command Errors-Command Errors occur when a valid HEADER packet is received that causes a Com- mand Sequence Error, Illegal Command Error, or Command Resource Unavailable Error. If requested in the HEADER packet, an ACKNOWLEDGE packet is returned despite the error condition’s arising. The response to Command Errors is to wait for the S-module’s S-Controller to enter its IDLE state as further detailed in 11.9.1, 11.10.1, and 11.12.1. The S-module will return NULLpackets for any packets requested beyond the ACKNOWLEDGE packet.
Data Packet Errors-Data Packet Errors may be divided into two types:
- Type 1: Those requiring the S-module to limit the transmission of data on the MSD signal in some way during transmission of a DATA packet and to wait for the S-module’s S-Controller to enter its EQM Slave Controller state. These include Stare. Sequence Emrs, MSD Collision Errors, Illegal Port Selection Errors, and Command Resource Unavailable Errors as detailed in 11.6.1, 11.7.1,
S-module to release the MSD signal. A State Sequence Error causes an uniquery Controller of that S- ; a broadcast or multicast addressed S-module will al urrent message when a State Sequence Error occurs. An Resource Unavailable Error causes the S-module to
include Port Transfer Errors bethrough 11.8.ld and 11.5.1.
dule’s S-Controller enters its XFER16 Slave Controller state while the S-module is not detailed in 11.4.1.
Post-Message Errors-Post-Message Errors are those enors that occur after the message has been termi- nated (i.e., when all formerly addressed S lers in their IDLE Slave Controller state). These errors include Incorrect Pac ansfer Errors. If the Acknowledge request bit was set in the HEADER pack and the bus enters EOM prior to the ACKNOWLEDGE packet transfer, the indicating an incorrect packet count (1 1.11. lb; 14.2.1). The PTE bit may be set while the bus is in EOM or IDLE in cases in which writing to a port selected in the immediately preceding message is not immediate so that an error during execution of the command transmitted by that message may occur sometime (i.e.$ several cycles of the MCLK signal) after the message is terminated.
14-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL Std 1149.1 E l '
NOTE-This diamond should contain the following text: "Command Sequence Error & EMC was previous command?"
NOTE-Messages begin with a HEADER packet. Header Errors (setting PRE or SSE) are treated as though the S-n were not addressed. If no Header Error occurs. the S-module uses the contents of the HEADER packet to deter1 that S-module is addressed. If an S-module determines that it is addressed, Command errors (setting CSE or IL captured if such occurred; and the message sequence continues through completion of an ACKNOWLEDGE packet fer (via connector A), if the Acknowledge Request bit was set in the HEADER packet.
Figure 14-2-MTM-Bus message sequence-part 1
5
c r
I
iEE 995
i -1
, 9 "d.
I
1, I
llule be if are ins-
14-5
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Slave Controller state
-------
have to have good parity.
1-SSE = State Seauence Error 2-Coli. = MSD Collision Error 3-Bracketed operations related to the MPR signal only apply if the latter is implemented.
NOTE-Assettion or release of MPR (8.3.1) may occur in any S-transfer state. Decision is analogous to that in dotted box G, above
NOTE-An S-module asserts MPR until it is ready to transmitlreceive additional packets following a HEADER packet by which it is addressed. When an S-module is in the DATA packet loop, it may be required to handle Illegal Packet Count, Data Overrun, Collision, Parity, and State Sequence Errors. Completion of transmission of an ACKNOWLEDGE packet or subsequent DATA packet brings the Message Sequence to connector D. Returning to connector E, occurs when error checking after the completion of a packet transmission has been completed.
15.1 MTM-Bus commands-general requirements on command codes and command classes
The seven-bit command field within a HEADER packet is interpreted by an S-module following the com- mand code definitions in figure 15-1. The MTM-Bus commands are divided into six classes: the Core class, the Data Transfer class, the Module Initialization and Self-Test (MIST) class, the Module U0 Control and Test class, the Standard-Extension class, and the User-Defined class.
When a command code is not used (does not decode to a command), it is said to be associated with an “unimplemented command.” If an unimplemented command code (i.e., the command code of an unimple- mented command) is contained in the HEADER packet of some message, it will be construed as an error (11.10.1).
15.1.1 Specifications
(a) The complete set of seven-bit command codes for MTM-Bus commands and the classes into which these commands are divided shall be as defined in table 15-1.
NOTE-These commands are conveyed to S-modules in the scvcn-hi1 Command field of a HEADER packet (5.2).
(b) User-Defined commands shall correspond only to seven-bit codes belonging to the User-Defined class.
(c) Commands defined by other standards organizations expanding upon this Standard shall correspond only to seven-bit codes belonging to the Standard Extension class.
(d) Any MTM-Bus S-module shall implement all se commands in table 15-1 that are marked “required” in the right-most column.
(e) Those commands marked by an asterisk in table 15-1
(i) shall be called critical control commands;
(ii) shall be transmitted in messages for which the immediately preceding message was an Enable Module Control message.
NOTE-Failure to transmit an Enable Module Control message immediately before a message contain- ing in its HEADER packet one of the command codes of a command marked by an asterisk in table 15-1 (a critical control command) gives rise to a Command Sequence Error (11.9.1). Since the EMC com- mand is used for no other purpose, its transmittal in a message not followed by a message with its HEADER packet containing a command code of a critical control command also gives rise to a Com- mand Sequence Error (11.9.1).
Recommendations
( f ) Any MTM-Bus S-module should implement all those commands in table 15-1 that are marked “recommended” in the right-most column.
15-1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
Permissions
(g) Standard-Extension and User-Defined commands may be implemented (clause 20).
15.1.2 Description
The seven-bit Command field within a HEADER packet is used to define the command to be executed by currently addressed S-modules. The basic command classes are described in table 15-1.
Table 15-1-MTM-Bus command codes
Command class Core
Data Transfer
Module U0 Control and Test (MICT)
Standard-Extension
User-Defined 'Indicates that an Enable Module (15.1.1e).
Command codes
0000000 OOOOOO1 m 1 0 m 1 1 oooOlXX o001OOO o001001 ooo1010 o001011 o001100 ooo1101 ooo1110 Ooollll 001 oooo 0011Kx)1
Contend for Bus Multicast Group Select Enable Idle lnterrupts Enable Pause Interrupts Disable Idle Inlermpts Disable Pause Interrupts Enable Module Control Data Echo Test Verify BMR '
Initial& Application a _I ' Disable Module Control a
Staa Reserved Illegal Command Read Data WFik Reamrite Data Rcscrvd Kzsct ~ k h u l c with SIC? I'
Kcscl Module willioul SR1'r '' Module BIT a
Reserved Disable Module U0 a
Enable Module U0 a
Force Module Outputs a
Sample Module-No Change a
Sample Module-Don't Care a
Sample Module with Force a
Release Module U0 Reserved Reserved for the use of standards- making bodies User-Defined commands : has to precede a message convt
Core class communds-All S-modules have to implement a small number of commands that are necessary to initialize the module, support the basic MTM-Bus protocol, and support MTM-Bus testing. The imple- mentation of these commands can be considered to be a virtual part of the MTM-Bus interface logic of an S- module. Even if some other command is being executed by an S-module when a Core class command is received, the Core class command has to be executed (14.1. le), requiring two potentially concurrently exe- cuting commands to be somehow partitioned. Since no command can be transmitted without starting a new message, the only commands that might be executing when a Core class command is received are those whose execution takes place after a message terminates.
As an example, consider the Abort command (16.2.1). Among the commands that might be aborted are,
- In the Core class, a previously transmitted Abort command and the Initialize Application command. - In the Data Transfer class, commands involving ports transferring data to functions that carry on
extensive post-message processing. - In the MIST class, all commands. - In the Module VO Control and Test class, the Force Module U 0 and the commands causing sampling
(most likely to have execution continuing significantly after termination of a message, but not by very many cycles of the MCLK signal).
- In the Standard Extension and User classw, chpletely open, requiring careful checking by develop- ers and users of S-modules.
Whether one of the following listed commands can possibly be aborted is application-dependent:
Data Transfer class comrnands-It is recommended that S-modules implement Data Transfer class com- mands (14.1. If) as they allow for the transfer of a wide variety of data types between the M-module and any number of ports within S-modules. These commands may be used for access to local memory, fault logs, on- module buses. etc.
Module Initialization and Self-Test (MIST} class commands-This set of recommended commands instruct addressed S-modules to perform Built-In Self-Test routines, or to perform resetting (9.2.lb; 9.3.lb; 9.4.lb; 9.5.lb) of the module. These commands are recommended to allow for a standardized and interoperable method for performing these various levels of initialization and self-test.
Module Z/O Control and Test class commands-Thb set of commands supports control and test of intercon- nections between modules. Although this testing may be implemented using techniques such as IEEE Std 1149.1 boundary-scan, these commands are generalized ta allow any number of structural implementation- s.Three possible approaches are suggested for sampling S-module inputs. One or all of the corresponding messages should be implemented.
Standard-Extension class commands-The set of command codes in this command class have been set aside for use by other standard-making bodies who may wish to adopt this Standard and extend its capability by adding commands.
User-Defined class commands-These commands are those developed by bus interface designers or module developers to meet the requirements of their specific applications. These commands may be implemented to execute in hardware, firmware, or software.
Table 18-1 relates the functions of Core class, MIST class, and MICT class commands useful in initializa- tion, resetting, and self-testing of an S-module. The functions of interest range from aborting a command to bringing an S-module back on-line after self-testing, initialization, or resetting. It will be noted that some of the complex commands can be built up step-wise by use of simpler commands in an appropriate sequence.
The following clauses provide the detailed requirements for the variety of command types.
15-3
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
15.2 Commands execution of which may be terminated upon receipt of another command
15.2.1 Specifications
Rules
(a) For every implemented MTM-Bus command, C, that is liable to termination caused by receipt of a message transmitting another MIM-Bus command, the manufacturer of an S-module shall doc- ument each of the following and relate these items to the commands that may cause the termination:
(i) the point(s) or period@) during execution of C when the termination may occur;
(ii) the consequences of such te&ation(s) or the fact &at the consequences are unpredictable;
(iii) any indicators accessible after termination of execution of C that would be of diagnostic value to the S-module's user;
(iv) the maximum number of cyclcs of thc dgn81 011 hlCT,K that innp occur between the time that the S-modules's S-Coiitr.c?llcr cntcrs its EUM S l a w Cviitrollcr s t m it1 the termination of an MTM-Bus message tnlnsniission caiisi fig 1criirin;iliou of cxccii[ioii 01' C and the time that all requirements of 16.2. I h arc satisfied;
(v) the impact (if any) OS !tic k ~ ~ 1 i i l i i l i i ) i i of excution ol' C; c m :ill d a t t i s rcgisters (clause 9) that may be implemented in ihat S-~ntxiolc.
NOTES
1-In some cases, intermptioii oL'a cuiim:iiid iriiglit w c c i ~ r iiI any point iii i~ olxri i i ioi i : a statement to this effect would satisfy 16.2.1~.
2-In case there is one point or a coni;iiiicc! ~ i i i ~ i i l w d;tI!ernal~~c point5 in ;I cominunds function at which a graceful termination is allowcd, LliC,<L: ha! c 10 In. tlcscrilxd by 1hz miiiiifadtircr along with (for each such pos- sible case) any indicators thai can IIC crl' dingiiostic vsluc lo Llic S-irlotiirlc's LIVX.
15.2.2 Discussion
A number of commands are not c:)icri~1ilious wit11 Ihc ioessagcx Iransiiii~li~ig them. It is possible that a subse- quent message (e.g., a Core class ni~;:ssage) iniglii Ix: reccivd by itii S-module still executing a command. The requirements of 15.2.1 are intciidcd to providc ;in S-iiiohk uscr will1 as much information about such conditions as is practicable.
The Core class commands (15.1.1a; table 15.1) are commands that all MTM-Bus S-modules have to be able to execute at any time (14.1. le; 15.1.2). These commands are defined in the present clause.
The Core class commands provide the most basic interface to an S-module’s MTM-Bus interface and also provide means of aborting activity of S-module applications.
- Access to status registers (including identification of the source(s) of an interrupt) is provided by the Read Status command (16.1.1), the Contend for Bus command (16.4.1), and the Verify BMR com- mand (16.12.1).
- The set of commands that abort S-module MTM-Bus command execution with varying effects with relation to resetting S-module circuitry has the organization presented in table 18-1. Among these, the only two in the Core class of commands are the Abort command (16.2.1) and the Reset Slave Sta- tus command (16.3.1). The Start command (16.15.1) is provided to allow an S-module to be made fully functional again after execution of an Initialization Application command (16.13.1) that leaves that S-module application halted.
- Multicast group programming is supplied by the set of four Multicast Select x commands (16.5.1). - Programming of permission to interrupt as described in clause 10 is provided by a set of four com-
mands: the Enable Idle Interrupts command (16.6.1), the Enable Pause Interrupts command (16.7.1), the Disable Idle Interrupts command (16.8.1), and the Disable Pause Interrupts command (16.9.1).
- Basic test capabilities are provided by the Data Echo Test command (16.11.1) and the Illegal com- mand (16.17.1).
- The capability of “unlocking” S-module interface control when required to allow control over the MTM-Bus is provided by the Enable Module Control (EMC) command (16.10.1). “Re-locking” of S-module interface control cited is provided by the Disable Module Control command (16.14.1).
The commands are described by defining message formats and S-module responses to singlecast messages including these commands. S-modules cannot transmit packets in response to Multicast or Broadcast com- mands except in response to the Contend for Bus (16.4.1) and Verify BMR (16.12.1) commands (8.2.la; 12.1.ld).
16.1 The Read Status command (0000000)
16.1.1 Specifications
(a) The message format of a Read Status message shall be as depicted in figure 16-1.
(b) Upon receipt of a Read Status message, an uniquely addressed S-module shall return an ACKNOWLEDGE packet, regardless of the state of both
(i) the Acknowledge Request bit in the HEADER packet and
(ii) the BSY bit of the Slave Status register.
(c) If, in a Read Status message, the transmitted ACKNOWLEDGE packet contains the indication that the BSY bit was set in the addressed S-module’s Slave Status register, that S-module
(i) shall respond to any additional packet transfers within the message by returning NULLpackets;
16-1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(ii) shall not clear the contents of the Bus Error register, Module Stabs register, or any additional status registers.
(d) If, in a Read Status message, the transmitted ACKNOWLEDGE packet contains the indication that the BSY bit was cleared in the addressed S-module’s Slave Status register, that S-module shall respond in any subsequent packet pair transfers within the message by first sending the contents of the Bus Error register, then the contents of the Module Status register, and then any number of packets with user-defined status in an order documented by the S-module’s manufacturer.
(e) If, in a Read Status message, both
(i) an S-module’s S-Controller enters its XFER16 Slave Controller state
(ii) the contents of all of that S-module’s status registers have been transferred in previous packets of the current message,
then the S-module shall respond by returning a NULL packet and shall not set the Port Transfer Error ( R E ) bit of the Bus Error register.
NOTE-Clearing the error bits o being cleared; however, &er set, could keep the BSE bit
BSE bit of the Slave Status register such is implemented) that, by being
(g) During a Read Status message addressed S-module of a DATA packet identified as Error bits in the Module
16.1.2 Description
The read status command is intended to provide a simple method for the M-module to get as much status about an S-module as it needs by transferring any number of status packets.
The singlecast message format for a Read Status message is shown in figure 16-1. An uniquely addressed S - module responds to the Read Status command by returning a single ACKNOWLEDGE packet, regardless of the state of the Acknowledge Request bit within the HEADER packet of the Read Status message. The ACKNOWLEDGE packet returned in response to a singlecast Read Status message does not reflect status that has changed as a result of the HEADER packet (5.3.1~). If the M-module does not terminate the mes- sage and the BSY bit is not set, S-module transmission of the ACKNOWLEDGE packet will be followed by transmission of DATA packets containing the contents of the Bus Error register, the Module Status register, and any number of packets containing user-defined status.
16-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
M-MODULE
IEEE Std 1149.5-1995
S-MODULE
,I This packet pair transfer 7 1 ACKNOWLEDGE is required.
. . . . .
. Below this line, any packet transfers that occur shall occur in the order designated by this Standard and documentation required of the manufacturer of a given S-module. Zero or more packet transfers are permitted up to the maximum indicated in the manu- facturer’s documenta-
NOTE-When a Read Status message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, nor- mal S-module processing that would be initiated by a singlecast Read Status message will take place (12.1.10; and status registers will be cleared as in a singlecast message.
Figure 16-l-Singlecast message format for a Read Status message
Once the packet containing the Slave Status register contents has been sent, the error indication bits of that register have to be cleared. This means that once the contents of the Bus Error register contents have been sent, the error bits and BMR bit within the Bus Error register are cleared. Note that the BMR bit indicates success/failure of the last broadcast or multicast message attempted (9.3. la; 9.3.lb; table 9.4), and will be set in all addressed S-modules at the conclusion of a swcessful execution of a broadcast/multicast Read Sta- tus command. Following the transmission of the Module Status register contents, the error bits within the Module Status register have to be cleared.
If an S-module’s BSY bit is set, that S-module still has to be able to return an ACKNOWLEDGE packet in response to the Read Status command. If an S-module has already transmitted the contents of all an S-mod- ule’s status registers and an additional packet-transfer is initiated by the M-module, the S-module will return a NULL packet; and the PTE bit in that S-module’s Bus Error register (11.1. IC; 16.1.1d) will not be set. This exception is intended to simplify the M-module software performing status reads from multiple module types.
Note that the M-module may terminate the message without causing a State Sequence Error following any packet transfer provided that the state sequence specified in figure 6-1 is followed (i.e., PAUSE-01; EOM-00; IDLE-00). APacket Counting Error could be induced in some cases (14.2.1).
Another method for reading S-module status registers is to implement the Read Data command (17.2.1). A Read Data command directed to the appropriate ports (21.1.1c), will return the contents of the S-module Sta- tus register, Bus Error register, Module Status register, or additional status registers. Note that unlike the Read Status command, the Read Data command may be used to provide a non-destructive read of the regis- ter contents (i.e., bits are not cleared following packet transfers).
16-3
IEEE Std 1149.5-1995 tEEE STANDARD FOR MODULE TEST AND
Once there are no further responses to repeated sending of Verify BMR messages, the M-module can cause the BMR bit to be reset in the Bus Error registers of all §-modules by using the Reset Slave Status command or the Read Status command. This is an excellent application for broadcast or multicast of a Read Status message to clear the BMR bits-if using a Reset Slave Status message is less desirable.
A Read Status message is not a critical control message.
16.2 Abort command (OOOOOOl)
16.2.1 Specifications
Rules
The message format of an Abort message shall be as depicted in figure 16-2.
Upon receipt of an Abort message that has been immediately preceded by an EMC message, an S - module addressed by both these messages
(i) shall cause termination of execution of any previously received MTM-Bus command that would otherwise cause the BSY bit of the S-module’s Slave Status register to be set;
(ii) shall wait in a safe mode defined ’s manufacturer’s documentation.
NOTES
1-Error handling in the case in is described in 11.9.lb.
2-After terminating comniiinc! Slave Status register will hc clc;nzd bcciltisc no M’I’M-Bus corimmand will be executing (9.2.1).
The maximum time IhiiI iui S-motlulc mny lakc 10 conildete the action specified in 16.2.lb(i) and achieve the safe motlc or 10.2. I b ( i i ) ~ l l i ~ l l bc tlocumcitlctl by the S-module’s manufacturer.
If the S-module actions required to meet the s of this command take sufficient time so that it is possible that the M-module might transmit another message while those actions were still underway, any resource required to execute such a command shall be regarded as unavailable
e necessary EMC message does not preccde a critical control message
n iis r~quirud by 16.2.1b(i), the BSY bit in an addressed S-module’s
( 1 1.1 2).
NOTELThe command in such an additional message shall not be executed. Handling of Command Resource Unavailable Errors are treated in 11.12.1.
16.2.2 Discussion
As previously noted (7.2; 14.1.2; 15.1.2; 15.2), the execution of many commands is coterminous with the end of the message conveying the command. Only commands that trigger activity in application logic can be aborted, because the others won’t be executing when an Abort message is being transmitted to the S-module in question (15.1.2).
An Abort message has to be preceded immediately by an EMC message.
The Abort message is used to rapidly stop activity initiated by MTM-Bus commands in the S-module(s) addressed by that message. It is especially useful if an S-module is threatening the system function. In such a case the function of that module initiated by MTM-Bus comman stopped. Even if determination of counter measures may take some time, the problem module will be quies- cent while such measures are being evaluated.
16-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
M-MODULE
1 HEADER I ____) ’
S-MODULE
r - 1 ACKNOWLEDGE This packet pair transfer PACKET COUNT 71 is optional (may occur).
NOTE-When an Abort message is broadcast or multicast, no S-module transmits anything (12.1 .Id).
Figure 16-2-Singlecast message format for an Abort message
16.3 Reset Slave Status command (000001 0)
16.3.1 Specifications
(a) The message format for a Reset Slave Status message shall be as depicted in figure 16-3.
(b) Upon receipt of a Reset Slave Status message immediately preceded by an EMC message, an S- module addressed by both messages shall terminate execution of any previously loaded MTM-Bus command.
NOTES 1-Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.lb.
2-After terminating command execution as required 16.3.lb and completion of the actions required by 16.3.lc, the BSY bit in an addressed S-module’s Slave Status register will be cleared because no MTM-Bus command will be executing (9.2.1).
(c) Upon receipt of a Reset Slave Status message immediately preceded by an EMC message, the status registers of an S-module addressed by both such messages shall be reset (9.2.lb; 9.3.lb; 9.4.lb; 9.5.lb) sufficiently rapidly so that the action shall be completed before transmission of a subsequent message can begin.
NOTEGReset condition of Slave Status and Bus Error registers are fixed by this Standard (table 9-2 and table 9-5).
16.3.2 Description
The Reset Slave Status command is a required command that allows the M-module to bring the MTM-Bus interface logic on S-modules to a known state. This command may be used in broadcast mode to perform such functions as to clear all pending interrupt requests from all S-modules. Such a function may be useful during power-up or after certain system faults in which faults propagate widely.
The message format for the Reset Slave Status command is shown in figure 16-3. A message transferring a Reset Slave Status command is a simple message. An ACKNOWLEDGE packet returned in a singlecast Reset Slave Status message does not reflect the reset operation performed upon execution of the present command.
16-5
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
M-MODULE §-MODULE
1 HEADER I
PACKET COUNT
NOTE-When a Reset Slave Status message is broadcast or multicast, no S-module transmits anything (12.1 .Id). How- ever, normal S-module processing that would be initiated by a singlecast Reset Slave Status message will take place (12.1 .if), and the addressed §-modules’ status registers will be reset.
Figure 16-3-Singlecast message format for a Reset Slave Status message
16.4 Contend for Bus command (OOOOOll)
16.4.1 Specifications
Rules
(a) The message format of a CO s depicted in figure 16-4.
(b) Upon receipt of a Contend set in that S-module’s Slave (i.e., has BSE or EVO sequence (16.4.ld).
(c) Upon receipt of a Contend for Bus CO of 16.4.lb shall release for Bus message.
ule that has the IIE bit or PIE bit -l), and has an interrupt pending
in a Contend for Bus
addressed S-modules not meeting the conditions
(d) Participation in a Contend S-module satisfying the conditions nstrained by 16.4.le) according to the the Acknowledge Request bit in the
of 16.4.lb shall transmit an message format of figure 16-4 HEADER packet of the current message.
NOTJZ-The Contend for Bus command is an explicit exception to the rule that an S-module addressed by a multicast or broadcast command does not transmit anything on MSD (12.1.1d).
(e) If an S-module detects a collision on MSD while returning the ACKNOWLEDGE packet per 16.4.ld, it shall be said to “lose” the Contend for Bus sequence and shall
(i) cease participation in the Contend for Bus sequence by releasing its MSD signal prior to the transmission of its next bit:
(ii) not set the SDF bit in its Bus Error register;
(iii) behave as though not addressed for the remainder of the Contend for Bus message.
16-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
( f ) If an S-module “wins” the Contend for Bus sequence by successfully transmitting its ACKNOWLEDGE packet without a collision, the S-module shall not clear any S-module status reg- ister bit except as a consequence of 16.4.lg through 16.4.1j.
NOTE-Under normal conditions (all S-modules having an unique address), there will be a single winner of a Contend for Bus sequence. The exception will occur if two or more S-modules are responding to the amnesia address (3.3.ld; 3.3.10.
(g) If permission 16.4.lj is implemented in a given S-module that wins a Contend for Bus sequence, then, if in a Contend for Bus message
(i) that S-module’s S-Controller enters its XFER16 Slave Controller state and
(ii) the contents of all of that S-module’s status registers have been transferred in previous packets of the current message,
then the S-module shall respond by returning a NULL packet and shall not set the Port Transfer Error (PTE) bit of the Bus Error register.
(h) If permission 16.4.lj is implemented in a given S-module that wins a Contend for Bus sequence, then in a Contend for Bus message following the transfer by that S-module of a packet containing the Bus Error register contents, bits <10..0> and any of bits <12..15> in the Bus Error register that are defined by module documentation to be cleared by the Read Status (16.1.1) command shall be, or shall have been, cleared.
then in a Contend for Bus message following the transfer by that S-module of a DATA packet con- taining the Module Status register contents or the ntents of an user-defined status register, those bits in the Module Status (user-defined status) reg that are defined by module documentation to be cleared by the Read Status command (16.1.1) shall be, or shall have been, cleared.
NOTE-Clearing the error bits of the Module Status register may result in the EVO bit of the Slave Status reg- ister being cleared; however, there may be bits in additional status registers (if such are implemented) that, by being set, could keep the EVO bit from being cleared (9.4.1; 9.5.1). A means of providing a re-read capability for registers that have been cleared by the Read Status command is recommended (9.1.1d).
Permissions
U) Upon winning a Contend for Bus sequence, an S-module may respond to additional packet pair transfers by providing the contents of that S-module’s Bus Error register, its Module Status register, and any user-defined status in the order determined by the rules of the Read Status command (16.1).
16.4.2 Description
The message format of the Contend for Bus command is shown in figure 16-4. The method by which a Con- tend for Bus sequence is used to identify sources of interrupts is illustrated by figure 16-5.
The Contend for Bus command provides a mechanism for isolating module interrupts (clause 10) that is faster than polling all S-modules and examining the status of each (via separate Read Status commands). An S-module will not participate in a Contend for Bus sequence if the IIE and PIE bits of its Slave Status regis- ter are both cleared (table 10-1).
16-7
IEEE Std 11 49.5-1 995
HEADER
M-MODULE
_____)
IEEE STANDARD FOR MODULE TEST AND
S-MODULE
Below this line, any packet transfers that occur shall occur in the order designated b this Standard and &cumentation required of the manufacturer
NULL I I Usedefined(1) I
I
of a given S-module. Zero or more packet transfers are permitted up to the maximum indicated in the manu- facturer’s documenta- tion.
Figure 16-4-Message format for a Contend for Bus message
An S-module wins a Contend for Bus sequence by successfully transmitting itsACKNOWLEDGE packet to the M-module without detecting a collision on the MSD signal. As shown in figure 16-5, S-modules transmit data on the MSD signal on the rising edge of the MCLK signal and have to have the capability to detect a collision on that signal (4.3.la; figure 4-1). When a collision is detected on the MSD signal by an S-module during transmission of a packet, that S-module immediately releases MSD (thereby dropping out of the Con- tend for Bus sequence before it can transmit another bit that might be a logic 1) without recording an error.
Since the MSD signal is implemented as a logical-OR, an S- e should never detect a collision when it is sourcing a logic 1 on the MSD signal. MTM-Bus pacEets are transmitted msb first and that the most-sig- nificant 8 bits of an ACKNOWLEDGE packet contain the module address of a responding S-module. When multiple S-modules try to respond to a Contend for Bus command by returning ACKNOWL each S-module’s collision detection circuitry provides a means of cornparison of that S- and the value on MSD. When an S-module has a lower module address than some other participating S- module, at some point in the ACKNOWLEDGE packet transfer the S-module with the lower address will detect a collision and drop out of the Contend for Bus sequence.
Assume three S-modules A, B, and C (having binary addresses of ‘10111000,’ ‘10100000,’ and ‘00110011,’ respectively) begin to participate in a Contend for Bus sequence. S-module C would drop out of the sequence following the falling edge of the MCLK signal after the bit<l6> of its ACKNOWLEDGE packet is transmitted. S-module B would drop out following the falling edge of the MCLK signal after bit<l3> of its ACKNOWLEDGE packet is transmitted (figure 16-5). S-module A emerges as the winner of the Contend for Bus sequence. Any S-modules that lose a Contend for Bus sequence and do not have error bits in status registers cleared by some other means will then assert an interrupt at the next time they are enabled to do so.
The S-module winning the Contend for Bus sequence may return the contents of the Bus Error register, Module Status register and any additional status registers in subsequent DATA packet transfers of the Con- tend for Bus message. The order of transmission of data from these registers is identical to the order described for the Read Status command (16.1).
16-8
MAINTENANCE BUS (MTM-BUS) PROTOCOL
-
HEADER - MMD
IEEE Std 1149.5-1995
-
PACKET COUNT - 1
MCTL T--l
MSD I I ACKNOWLEDGE I
- MCLK
~ _ _
MCTL - 2 clocks + S-module 1 continues to transmit an ACKNOWLEDGEpacket after the collision.
.- -.
MSD I BIT 16 BIT15 BIT 14 L B I T 13 1 2 T 1 2 h\T S-moduleA ~. .- I -.
MSD remains released to end of message except for
-
.- MSD BIT 16 1 BIT 15 [ B I T 14 1
collision occurs. '2 -. -. S-moduleB ___-
NOTE-In the example of figi:r(! 16-5. 1-0 S-mili:'es are participating in a Contend for Bus sequence. Both S-modules transmit the same value for c x i i ci :'io first i l w o t?ils of the ACKNOWLEDGE packet. However, when bit<l3> of the packet is transmitted, S-module 2 :It:<>rri[:k lo :miln\srr!il ;I I:)jic 0. The collision detection circuitry of the MSD signal on S-module 2 detects a collision. As a consequence, S-module 2 ceases to participate in the Contend for Bus sequence. Precisely when the collision is detected in S-module 2 is not verifiable externally. The requirements of this Standard simply specify the de- sired behavior-that the MSD signal shall not be asserted by S-module 2 for the remainder of the message except when signalling a permitted interrupt.
Figure 16-5-Contend for Bus operations are used to identify which S-module sourced an interr
MTM-Bus status registers will not be cleared following the transmission of the ACKNOWLEDGE packet in response to a Contend for Bus command so as to prevent the loss of information if an error occurs during the contend operation. However, should permission 16.4.li be implemented in a given S-module, then during a Contend for Bus message in which the Bus Error register or the Module Status register contents are transmit- ted, those bits in these registers liable to being cleared during a Read Status message (16.1.1) will be cleared.
16.5 Multicast Select n commands (n = 0, 1,2,3) (0000100-0000111)
16.5.1 Specifications
(a) The message format for a Multicast Select n message shall be as depicted in figure 16-6.
16-9
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(b) Upon receipt of a Multicast Select n message (n = 0, 1, 2, 3), an addressed S-module shall set bits<3..2> in its Slave Status register (9.2.1; table 9-3 j M S 0 and MSl-equal to bits<3..2> of the HEADER packet of that message.
NOTE---Bitsd..2> of an HEADER packet correspond to the two lowest order bits of that packet’s Command field (5.2.1; figure 5-1).
16.5.2 Description
The format for a Multicast Select n message is shown in figure 16-6. If an ACKNOWEDGE packet is requested in a singlecast Multicast Select n message, the contents of that packet will not reflect changes to the multicast select bits due to the received Multicast Select n command.
M-MODULE S-MODULE
NOTE-When a Multicast Select nmessage is broadcast or normal S-module processing that would be initiated by a sin
::;msmits anything (12.1.1d). However, i irmessage will take place (12.1.1f).
Figure 16-&Singlecast message format for a Multicast Select n message
Table 16-1-Effect of Multicast Sefect n commands
ur cwmmana I
ooooioo Assign S-module I to multicast group 0
The Multicast Select n commands allows an S-module to be programmed to be in any one of four multicast select groups (3.3.1; 9.2.1; table 9-3; table 16-1). The M-module may communicate with all S-modules within a multicast group by using the appropriate multicast address. The binary patterns of the command codes of the Multicast Select n commands have been selected so that the two least significant bits of the command code equal the new values for the MSO and MSl bits of an addressed S-module’s Slave Status register.
16-10
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
16.6 Enable Idle Interrupts command (0001 000)
16.6.1 Specifications
(a) The message format for an Enable Idle Interrupts message shall be as depicted in figure 16-7.
(b) Upon receipt of an Enable Idle Interrupts message, an addressed S-module shall set the Idle Inter- rupts Enabled (IIE) bit in its Slave Status register.
16.6.2 Description
The message format for the Enable Idle Interrupts command is shown in figure 16-7. If an ACKNOWL- EDGE packet is requested in a singlecast Enable Idle Interrupts message, the contents of that packet will not reflect the setting of the IIE bit (5.3.1~; 9.2; 10.1; table 10-1).
M-MODULE S-MODULE
ACKNOWLEDGE This packetpair transfer is optional (may mcud.
NOTE-When an Enable Idle Int e is broadcast or multicast, no S-module transmits anything (12.1.1d). However, normal S-module processing that would be initiated by a singlecast Enable Idle Interrupts message will take place (12.1.lf).
Figure 16-7-Singlecast message format for an Enable Idle Interrupts message
16.7 Enable Pause Interrupts command (0001 001)
16.7.1 Specifications
(a) The message format for an Enable Pause Interrupts message shall be as depicted in figure 16-8.
(b) Upon receipt of an Enable Pause Interrupts message, an addressed S-module shall set the Pause Interrupts Enabled (PIE) bit in its Slave Status register.
16.7.2 Description
The message format for the Enable Pause Interrupts command is shown in figure 16-8. If an ACKNOWL- EDGE packet is requested in a singlecast Enable Pause Interrupts message, the data in that packet will not reflect the setting of the PIE bit (5.3.1~; 9.2; 10.1; table 10-1).
16-11
IEEE Std 1149.5-1995
HEADER
M-MODULE - S-MODULE
IEEE STANDARD FOR MODULE TEST AND
NOTE-When an Enable Pause Interrupts message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-module processing that would be initiated by a singlecast Enable Pause Interrupts message will take place (12.1.1f).
Figure 16-&-Singlecast message format for an Enable Pause Interrupts Message
16.8 Disable Idle Interrupts command (0001010)
16.8.1 Specifications
Rules
(a) The message forma
(b) Upon receipt of a Disable Id rupts Enabled (IIE) bit in its
The message format for the EDGE packet is requested in a singlecast message, IIE bit (5.3.1~; 9.2; 10.1; table 10-1).
in that packet will not reflect the clearing of the
M-MODULE DULE
HEADER - 1-J - ACKNOWLEDGE This packet pair transfer PACKET COUNT - I is optional (may occud.
NOTE-When a Disable Idle Interrupts message is broadcast or multicast, no S-module transmits anything (12.1 .Id). How- ever, normal S-module processing that would be initiated by a singlecast Disable Idle Interrupts message will take place (1 2.1 . 1 f).
Figure 16-9-Singlecast message format for a Disable Idle Interrupts message
16-12
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
16.9 Disable Pause Interrupts command (0001011)
16.9.1 Specifications
(a) ADisable Pause Interrupts message shall have the format depicted in figure 16-10.
(b) Upon receipt of a Disable Pause Interrupts message, an addressed S-module shall clear the Pause Interrupts Enabled (PIE) bit in its Slave Status register.
16.9.2 Description
The message format for the Disable Pause Interrupts command is shown in figure 16-10. If an ACKNOWL- EDGE packet is requested in a singlecast Disable Pause Interrupts message, the data in that packet contents will not reflect the clearing of the PIE bit (5.3.1~; 9.2; 10.1; table 10-1).
M-MODULE S-MODULE
__.
ACKNOWLEDGE This packetpair transfer L A is optional (may occuo.
NOTE-When a Disable Pause Interrupts message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-module processing that would be initiated by a singlecast Disable Pause Interrupts message will take place (12.1.1f).
Figure 16-1 O-Singlecast message format for a Disable Pause Interrupts message
16.10 Enable Module Control (EMC) command (0001100)
16.10.1 Specifications
(a) The message format for an EMC message shall be as depicted in figure 16-1 1.
(b) Upon receipt of an EMC message, an addressed S-module shall record receipt of the EMC command.
(c) An S-module shall delete its record of having received the EMC command
(i) subsequent to the receipt of any HEADER packet;
N O T S T h e record of receipt of the EMC command is deleted upon receipt of an HEADER packet regardless of whether the S-mo dule is addressed in that HEADER packet.
16-13
lEEE Std 1149.5-1995 lEEE STANDARD FOR MODULE TEST AND
(ii) upon detection of a faulty HEADER packet (i.e., detection of a Parity Error or State Sequence Error).
NOTE--Nevertheless, error handling for Command Sequence Errors will be activated because no S- module can become addressed upon receipt of a faulty HEADER packet (11.5.1a; 11.6.la). Failure to be addressed in a message following an EMC message will trigger the Command Sequence Error response (1 1.9.1 a).
Permissions
(d) An S-module may be designed to delete its record of having received an EMC message after a doc- umented number of cycles of the MCLK signal.
NOTE-11.9.le requires that, in an S-module implementing 16.10.ld, the action of deleting a record of hav- ing received an EMC message pursuant to a time-out as described in 16.10.ld has to cause the CSE bit of the Bus Error register to be set.
16.10.2 Description
The message format for an EMC message is shown in figure 16-1 1.
The EMC command can be thought of as a command that unlocks a mechanism preventing inadvertent exe- cution of commands that have * . ’<:..,.: I, : . : on the operation of an addressed S-module or the system in which it resides. The EMC CO I 1. :.i ,I receiving module to execute a critical control function that may affect the state or operation of the module’s application circuitry. A11 EMC message has to precede any message conveying a command marked by an asterisk (*) in table 15-1. Thqse commands are called critical control commands. If a critical control command is received by an S- in a message not immediately preceded by an EMC message, then that S-inodules will not execule tical control command, and the Command Sequence Error (CSE) bit of the Bus Error register will be set (11.9.lb). Likewise, if an S-module receives an EMC message that is not followed by a message conveying a critical control command, a Com- mand Sequence Error is recorded (1 1.9. la). Actions in response to Command Sequence Errors are treated in
. -
11.9.1.
M-MODULE S-MODULE
This packet pair transfer C 1-1 is opgona/ (may occud.
NOTE-When an EMC message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S- module processing that would be initiated by a singlecast EMC message will take place (12.1.19.
Figure lbll-Singlecast message format for an EMC message
Note that a “time-out” may be implemented within S-modules for the EMC command. Such a time-out may improve the protection provided by the EMC mechanism.
16-14
IEEE Std 1149.5-1995 MAINTENANCE BUS (MTM-BUS) PROTOCOL
16.1 1 Data Echo Test command (0001 101)
16.1 1.1 Specifications
Rules
(a) The message format for a Data Echo Test singlecast message shall be as depicted in figure 16-12.
NOTE-Packet latency in a Data Echo Test singlecast message is one.
(b) Upon receipt of the HEADER packet of a Data Echo Test message and regardless of the state of the Acknowledge Request bit in the HEADER packet of that message, an addressed S-module shall respond in all future packet transfers by transmitting a packet that is the exact duplicate of the packet last sent by the M-module-beginning with the HEADER packet (figure 16-12).
NOTE-Despite the name of this command, no echoing of data will occur in cases in which the command is transmitted in a multicast or broadcast message (12.1.1d).
If an S-module receives a DATA packet with incorrect parity as part of a Data Echo Test message, the S-module shall echo the DATA packet as received (i.e., with bad parity intact).
NOTE-This is consistent with error handling for Parity Errors (1 1.5.1).
16.1 1.2 Description
The message format for the Data Echo Test message is defined in figure 16-12.
No ACKNOWLEDGEpackefi PACKE J COUN Jpacketpair can be transmiitteed regadless of the state of the Acknowldge Request bit in the HEADERpacket (74.7.7b).
M-MODULE
U
DATA (1 )
._.
I I
At least one DATA packet shaff A -1 be transmitted by the M-modufe. -
.
NOTE-When a Data Echo Test message is broadcast or multicast, no S-module transmits anything (12.1.1d). However, normal S-module processing that would be initiated by a singlecast Data Echo Test message will take place (12.1 .If).
Figure 16-12-Singlecast message format for a Data Echo Test message
Note that it is necessary for the HEADER packet of a Data Echo Test message to be echoed because there will never be an ACKNOWLEDGE packet returned in response to this command, even if the Acknowledge Request bit in the HEADER packet is set.
16-15
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
When an addressed S-module receives the Data Echo Test command, the S-module is placed into a special mode in which each packet transfer from the S-module will consist of the last packet the S-module has received from the M-module. Echoed packets will have exactly the same 17-bit pattern as the received packet--even in the case of a packet with bad parity.
The Data Echo Test command may be used to test MTM-Bus backplane traces and MTM-Bus S-module interface circuitry by sending DATA packets containing arbitmy binary patterns. This command may also be used to test the parity checking logic of the M-module by having the addressed S-module echo a packet that contains bad parity. The Data Echo Test command (when broadcast or multicast) is a means by which the parity checking logic of several S-modules can be checked simultaneously.
16.12 Verify BMR command (0001110)
16.1 2.1 Specifications
(a) The message format for the Verify BMX Command shall be as illustrated in figure 16-13.
(b) Upon receipt of a Verify BMR command, addressed S-modules with the BMR bit in their Bus Error registers (9.3.1) set shal
(c) In response to receipt of register (9.3.1) cZeared s state of the Acknowledg
NOTE--The Verify BMR ticast or broadcast command does not trans
(d) If an S-module detects a collision on MSD
ith the BMR bit in its Bus Error (figure 16-13), regardless of the
g the ACKNOWLEDGE packet required by 16.12.lcandfigure 1 mission of the next bit of the ACKNOWLEDGE packet and shall not set the SDF bit in the Bus Error register (9.3.1).
(e) An S-module not detecting a col required by 16.12.1~ and figure 1 (9.3.1) and shall not clear any bits quence of 16.12.lf through 16.12.
. sion of the ACKNOWLEDGE packet t in that S-module’s Bus Error register tatus register (9.2.1) except as a conse-
(f) If permission 16.12.1i is implemented in a given S-module and that S-module satisfies the conditions of 16.12. l e in a given Verify BMR message, then, if in that same message
(i) that S-module’s S-Controller enters its XFER16 Slave Controller state and
(ii) the contents of all of that S-module’s status registers have been transferred in previous packets of the current message,
the S-module shall respond by returning a NULL packet and shall not set the Port Transfer Error (PTE) bit of the Bus Error register.
(g) If permission 16.12.li is implemented in a given S-module and that S-module satisfies the conditions of 16.12. l e in a given Verify BMR message, then in that same message following the transfer by that S-module of a packet containing the Bus Error register contents, bits <10..0> and any of bits
16-16
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
<12..15> in the Bus Error register that are defined by module documentation to be cleared by the Read Status command (16.1.1) shall be, or shall have been, cleared.
NOTE-Clearing the error bits of the Bus Error register may result in the BSE bit of the Slave Status register being cleared; however, there may be bits in a Module Status register (if such is implemented) that, by being set, could keep the BSE bit from being cleared (9.3.1; 9.4.1). A means of providing a re-read capability for registers that have been cleared by the Read Status command is recommended (9.l.ld).
(h) If permission 16.12.li is implemented in a given S-module and that S-module satisfies the conditions of 16.12.le during a given Verify BMR message, then in that same message following the transfer by that S-module of a DATA packet containing the Module Status register contents, those bits in the Module Status register that are defined by module documentation to be cleared by the Read Status command (16.1.1) shall be, or shall have been, cleared.
NOTE-Clearing the error bits of the Module Status register may result in the EVO bit of the Slave Status reg- ister being cleared; however, there may be bits in an additional status register (if such is implemented) that, by being set, could keep the EVO bit from being cleared (9.4.1; 9.5.1). A means of providing a re-read capability for registers that have been cleared by the Read Status command is recommended (9.1.1d).
Permissions
(i) Upon satisfying the conditions of 16.12.le in a given Verify BMR message, an S-module may respond to additional packet pair transfers in that same message by providing the contents of that S- module’s Bus Error register, its Module Status register, and any user-defined status in the order deter- mined by the rules of the Read Status command (16.1.1).
16.12.2 Description
The Verify BMR command is intended to simplify the process of verifying that all S-modules received the HEADER packet of a previously broadcast message or that all S-modules in a multicast group received the HEADER packet of a previously sent multicast message.
All addressed S-modules with the BMR bit in their Bus Error registers (9.3.1) clear respond to this command by returning an ACKNOWLEDGE packet in the same fashion as in the Contend for Bus (16.4.1) com- mand-they “listen” for higher value addresses than their own and immediately stop transmitting when an higher address is “heard.” As with the Contend for Bus command, further transfers in the same message will return additional status words as detailed in the Read Status command (16.1.1). The “winning” S-module will set its BMR bit in its Bus Error register. This setting of the BMR bit prevents the S-module from responding if the M-module transmits a second consecutive Verify BMR command to check the BMR bit status in other S-modules. Once there are no further responses to repeated sending of Verify BMR messages, the M-module can cause the BMR bit to be reset in the Bus Error registers of all S-modules by using the Reset Slave Status command or the Read Status command. This is an excellent application for broadcast or multicast of a Read Status message to clear the BMR bits-if using a Reset Slave Status message is less desirable.
16-17
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
Below this line, any
occur shall occur in 7-1 packet transfers that
the order designated b this Standard and &cumentation required of the manufacturer of a given S-module. Zero or more packet transfers are permitted up to the maximum indicated in the manu- facturer’s documenta- tion.
Figure 16-13-Message format for a Verify BMR message
16.13 The Initialize Application command (0001117)
16.1 3.1 Specifications
Rules
(a) The format of an Initialize Application mes defined in figure 16-14.
(b) Upon its S-Controller’s entering the EOM Slave Controller state at the termination of an of an Ini- tialize Application message that has been immediately preceded by an EMC message, an S-module addressed by both these messages
(i) shall cause termination of execution of any previously receivcd MTM-Bus command that would otherwise cause the BSY bit ofthe S-module’s Slave Status register to be set;
NOTELAS a result of 16.13.1b(i), the BSY bit of such an S-module’s Slave Status register will be cleared once the Initialize Application command has been executed.
(ii) shall be initialized to a specific, manufacturerdocumented state.
NOTEL-Error handling in the case in which the necessaiy EMC message does not precede a critical con- trol message is described in 11.9.1 b.
(c) The maximum time that an S-module may take ta complete the actions described in 16.13. lb shall be documented by the S-module’s supplier.
(d) If the S-module actions required to meet the requirements of this command take sufficient time so that it is possible that the M-module might transmit another message while those actions were still underway, any resource required to execute such a command shall be regarded as unavailable (1 1.12).
16-18
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
NOTE-The command in such an additional message shall not be executed. Handling of Command Resource Unavailable Errors are treated in 11.12.1.
Permissions
(e) Following satisfaction of 16.13.lb, an S-module executing the Initialize Application command may be returned to full functional operation.
16.13.2 Description
The Initialize Application command is provided to allow a system to be initialized via the MTM-Bus. Mod- ule initialization sequences are based upon each S-module’s application logic and may be different than a module power-up sequence. S-modules containing processors might re-initialize the processor(s) and begin executing the module’s start-up code. S-modules without processors might be initialized by causing an S- module reset (9.2.lb, 9.3.lb, 9.4.lb, 9.5.lb) to occur. Execution of this command includes aborting any cur- rently executing MTM-Bus command (e.g., a self-test sequence), forcing S-module application circuitry to a known initial state as defined by the module’s documentation, beginning module functional operation.
NOTE-When an Initialize Application message is broadcast or multicast, no S-module transmits anything (12.1 .Id). How- ever, normal S-module processing that would be initiated by a singlecast Initialize Application message will take place (12.1.19.
Figure 16-1 &Singlecast message format for an Initialize Application message
The message format for the Initialize Application command is shown in figure 16-14. The Initialize Applica- tion command has to be proceeded immediately by an EMC command since the Initialize Application com- mand will affect the operation and state of the module. The ACKNOWLEDGE packet (if requested in the HEADER packet) does not reflect the results of the Initialize Application command execution. The module is initialized following the optional transfer of the ACKNOWLEDGE packet.
16.1 4 Disable Module Control command (001 0000)
16.14.1 Specifications
(a) The message format for the Disable Module Control Command shall be as illustrated in figure 16-15.
(b) Upon receipt of a Disable Module Control message immediately preceded by an EMC message, an S-module addressed by both these messages shall delete any existing record (16.10. lb) of the receipt of an EMC message.
NOTE-This command provides the only means of negating the effect of an EMC message without causing a Command Sequence Error.
16-19
IEEE Std 1149.5-1995
HEADER
IEEE STANDARD FOR MODULE TEST AND
____)
16.1 4.2 Description
The message format for a Disable Module Control message is depicted in figure 16-15.
It is necessary for the Disable Module Control command to be a critical control command so that no Com- mand Sequence Error will occur when the attempt is being made to disable the mechanism that would cause such an error.
M-MODULE S-MODULE
NOTE-When a Disable Module Control message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-module processing that would be initiated by a singlecast Disable Module Control message will take place (12.1.1f).
Figure 16-1 EE-Singlecast odule Control message
16.15 Start command (001000
16.15.1 Specifications
Rules
(a) The message format for the
(b) Upon its S-Controller's entering the EOM Slave Controller state at the termination of a Start sage, an S-module addressed by both operation.
message that has been immediate1 these messages shall insure that S
NOTE-Error handling in the case in whi sage is described in 11.9.lb.
ge does not precede a critical control mes-
M-MODULE S - M 0 D U L E
NOTE-When a Start message is broadcast or multicast, no S-module transmits anything (12.1.1d). However, normal S- module processing that would be initiated by a singlecast Start message will take place (12.1.1f).
Figure 16-1 &Singlecast message format for the Start command
16-20
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
16.1 5.2 Description
It may be desirable to apply the Initialize Application command prior to application of the Start command in an implementation in which the documented state resulting from execution of the Initialize Application com- mand is static-the application is halted. The Start command provides the capability of leaving this state.
16.1 6 Resewed commands (001 001 0-001 11 11)
16.16.1 Specifications
(a) An S-module shall respond to any of the Core class reserved commands in the same manner as is specified for the Illegal Command (16.17.1).
16.1 6.2 Description
The reserved commands are reserved for future revisions of the MTM-Bus. They are not to be defined by the user. The command decodes for user-defined commands are identified and specified in table 15-1 and clause 20.
16.17 Illegal command (1111111
16.17.1 Specifications
Rules
20.
16.17 Illegal command (1111111
16.17.1 Specifications
(a) If an S-module receives a message containing in the command code field of its HEADER packet the command code of the Illegal command, no action shall be taken other than those specified in clause 9 and in 11.10.1.
16.17.2 Description
The Illegal command is defined to allow S-modules to detect stuck-at 1 conditions on the MMD signal. As all MTM-Bus packets have odd parity on 17-bit packets, a stuck-at one condition on the MMD signal would not be detected as an error by an S-module’s parity checking logic.
An all-ones word would result in a module address of “IT” HEX, a command field of “1 11 11 11” binary, and the Acknowledge Request bit would be at a logic 1. Since the “FF” HEX module address is the address sued to access multicast group 3, the all-ones command is reserved to prevent the S-modules id multicast group 3 from unintentionally executing an instruction with an all-ones decode during a stuck bus condition.
When an S-module receives this illegal command, it will set the ILC bit of the Bus Error register (1 1.10. l), giving rise to an interrupt if it is permitted to do so by its current programming. Note that if an ACKNOWL- EDGE packet is requested, it will not reflect the setting of the BSE bit due to the setting of the ILC bit in the Bus Error register (5.3.1~).
16-2 1
IEEE Std 1149.5-1995
17. MTM-Bus Message Layer: Data Transfer class commands (01 00000-01 001 11)
The Data Transfer class commands allow the MTM-Bus to be used to transfer a wide variety of data types to and from a wide variety of destinations. Data Transfer class commands cause data to be transferred from the M-module to an S-module. On the receiving S-module, these data are further directed to an S-module port (clause 21). The concept of a port is not tightly specified to allow as much flexibility as possible.
17.1 General format requirements for Data Transfer class commands
17.1.1 Specifications
(a) Each Data Transfer class message shall identify the port selected by that message by means of a Port Identifier (PORT ID) packet (figure 17-1) that shall be transmitted from the M-module to the addressed S-module(s)
(i) as the first packet transferred following the transfer of the HEADER packet if no PACKET COUNTpacket is transferred in the given message;
(ii) as the first packet transferred following the transfer of the PACKET COUNT packet otherwise.
(b) A Port Identifier shall be a 16-bit binary number.
(c) Following transmission of the PORT ID packet (17.1.1 programming of a function receivinghansmitting data in an addressed S-module’s manufacturer’s documentation (figure 17-1).
addressing within the selected port or t port shall be as specified for that port
(d) No port of a given S-module shall remain selected when the S-Controller of that S-module is in its EOM Slave Controller state.
17.1.2 Description
Each Data Transfer class message identifies the port with which the application controlling the M-module will be communicating by including a PORT ID packet as shown in figure 17-1. If the packet containing the Port Identifier does not correspond to an implemented port, the addressed S-module(s) will take the actions required by 11.8.1.
A MTM-Bus data transfer port may or may not support the full set of MTM-Bus Data Transfer class com- mands. Furthermore, the message format of Data Transfer class commands are (in part) specific to the port addressed. Data transfer ports are defined in clause 21. In the same clause, a number of recommended ports are described in detail.
As shown in figure 17-1, the transfer of the Port Identifier may be followed by a port-specific addressing syntax. This addressing syntax may consist of any number of packets and may also include an indication of the number of packets to be transferred. Requirements for data transfer ports are specified in clause 21. In the same clause, a number of recommended and permitted ports are defined.
17-1
IEEE Std 1149.5-1995
HEADER
IEEE STANDARD FOR MODULE TEST AND
.
A Data Transfer class command may be used to transfer any number of data packets between the addressed S-module(s) and the M-module. These commands may be used to access individual status and control regis- ters, on-module memory, or IEEE Std 1149.1 scan paths.
M-MODULE S-MODULE
This packet pair fransfer isrequired r---zKq f
Potf-specXcpan’ion of message hort-specfic addresing syn fa, transfer of DR ?Z packe fs, e fc.1
NOTES 1 -The port-specific portion of Data Transfer class command 21.
formats are treated on a port-by-port basis in clause
2-When a Data Transfer class message is broadcast or muftkast, no S-module transmits anything (12.1.1d). However, normal S-module processing that would be initiated by a singfecast of the same message will take place (12.1 .If).
Figure 17-1-Beginning of sing
17.2 Read Data command (01
17.2.1 Specifications
at for Data Transfer class commands
Rules
(a) The message format of a singlecast Read Data message shall be as defined in figure 17-2, including embedded text.
(b) The message format of a multicast or broadcast Read Data message shall be as defined in figure 17-1 and shall have no port-specific part.
(c) The execution of the Read Data command by an addressed S-module shall consist of the following, conducted in a manner defined by the S-module manufacturer’s user documentation:
(i) selecting the port identified in the Read Data message’s PORT ID packet;
(ii) any action required to generate the requested data and make it available for transmission via the selected port;
(iii) reading data from the selected port in a manner defined in the S-module manufacturer’s module documentation:
(iv) formatting all data read from the selected port into 16-bit segments and adding odd panty to form appropriate DATA packets;
(v) transmitting resulting DATA packets to the M-module.
17-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
PORT ID
IEEE Std 1149.5-1995
NULL . -
17.2.2 Description
The Read Data command is used to transfer any number of DATA packets from an uniquely addressed S- module to the M-module. AS shown in figure 17-2, the message format is the same as for other Data Transfer class commands except that once the port-specific addressing has been completed, non-NULL DATA pack- ets are transmitted only from the addressed S-module while the M-module transmits NULL packets,
Following the port-specific addressing portion of a Read Data message, the selected port will source data for each subsequent DATA packet transfer. The data to be expected from a given port addressed in a given way is implementation-dependent. Likewise, any order or other organization of these data are implementation- dependent. If a selected port is not ready to transfer data, the S-module may assert the MPR signal (if it is implemented) to request a pause in message transmission by the M-module until additional data are avail- able from the port.
M-MODULE S-MODULE
L - I I
-- Port-specific portion of message -
1 NULL I
I NULL 1 . .
I NULL
. . .
This packet pair transfer is optional (may muo.
This packet pair transfer is required
In a Read Data message, zero or more DA ?A packets shallh transmiitledby the . S-module in the port-specific portion of the message.
In a Read Data message, the M-module shall transmit on& NULL packets in the port-specific portion of the message.
NOTE-When a Read Data message is broadcast or multicast, no S-module transmits anything (12.1.1d), and there is no port-specific portion of such a message (17.2.lb). However, normal S-module processing that would be initiated by a sin- glecast of the same message will take place (12.1.lf).
Figure 17-2-Singlecast message format for the Read Data command
17-3
IEEE Std 114951995 IEEE STANDARD FOR MODULE TEST AND
17.3 Write Data command (0100001)
17.3.1 Specifications
(a) The message format of a Write Data message shall be as specified in figure 17-3 including embedded text.
(b) The execution of the Write Data command by an addressed S-module shall consist of the following conducted in a manner defined by the S-module manufacturer’s user documentation:
(i) selecting the port identified in the Write Data message’s Port ID packet;
(ii) writing all data in subsequently M-module transmitted DATA packets to the selected port;
(iii) port-specific action on (or response to) such data.
Permissions
(c) An uniquely addressed S-mod command may, during the port-specific latency on the MSD signal the DATA portion of the Write Data mes
packets received on the MVfD sign
17.3.2 Description
The Write Data command is used S-module( s) .
This data may include some initial transmitted to some function via the selected port.
to a selected port on the addressed
ng usually followed by data to be
An uniquely addressed S-module may provide immediate back to the M-module by echoing data received with a packet latency of zero. This can serve as a mechanism to aid the M-module in checking on what data the S-module is receiving. The S ta bit on the MMD signal and place the same value on the MSD signal two cycles
17-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL
M-MODULE
IEEE Std 11 49.5-1 995
S-MODULE
ACKNOWLEDGE 7 1 e 7 1 optiona/(mayomud. This packet pair transfer is
This packet pair transfer is r i G 7 b - l -1 required
-- port-specific portion of message--
DATA 0 I - I NULLorDATAO I
NOTES The port-specific portion of a Wife Data message shal consist of zero or more packet pair transfex 7-An uniquely addressed S-module may echo data received from the M-module with a packet latency of zero instead of sending NULL packets.
Z-an S-module that is addressed by a broadast or multicast message is fohdden to transmit data.
NOTE-When a Write Data message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1 .If).
Figure 17-3-Singlecast message format for the Write Data command
17.4 ReadMlrite Data command (01 0001 0)
17.4.1 Specifications
Rules
(a) The message format of a Reamr i t e Data message shall be as specified in figure 17-4, including embedded text.
(b) The execution of the Reamr i t e Data command by an uniquely addressed S-module shall consist of the following conducted in a manner defined by the S-module manufacturer’s user documen- tation:
(i) selecting the port identified in the Reamr i t e Data message’s Port ID packet;
(ii) writing all data in subsequent M-module transmitted DATA packets to the selected port;
(iii) any action required to store or utilize the data written to the selected port;
(iv) any action required to generate the data to be read from the port and make it available for trans- mission via the selected port;
17-5
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(v) reading data from the selected port;
(vi) formatting all data read from the selected port into 16 bit segments and adding odd parity to form appropriate DATA packets:
(vii) transmitting resulting DATA packets to the M-module.
(c) The packet latency of the port-specific part of a ReadNrite Data message shall be specified in the port documentation.
17.4.2 Description
The R e a m r i t e Data command is used to transfer data from both the M-module and an uniquely addressed S-module within a single message. As shown in figure 17-4, the message format is the same as for other Data Transfer class commands except that in the port-specific portion of the message, data packets are both read from, and written to, the addressed S-module.
If a selected port is not ready to transfer data at some point in a R e a m r i t e Data message, the S-module may assert the MPR signal until the port is ready to receive/transr& additional data.
For R e a m r i t e Data messages, packet latency ha
M-MODULE
This packet pair transfer is op~onal (may occud.
This packet pair transfer is
ReaWdte Data message shall ontain L packetpair transfers of
this ype, where L is the packet latency of the port-specific portion of the message.
*A Read/write Data message shall contain zero or more packet pair transfers of this Vpe.
A ReacPWMe Data message shall Fcontain L packet pair transfers of
/a fency of the port-specific portion of the message.
-1 -1
NULL 7 1 this ppe, where L is the packet 1
NOTE-When a Readwrite Data message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1.19.
Figure 17-&Singlecast message format for the Reamrite Data command
17-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
17.5 Reserved commands (0100011-0100111)
17.5.1 Specifications
(a) An S-module shall respond to any of the Data Transfer class reserved commands in the manner spec- ified for response to the Illegal command (16.17.1).
17.5.2 Description
The command codes 01OOO11-0100111 are reserved for future revisions of this Standard. They are not to be defined by the user. The command codes for user-defined commands are identified and specified in table 15-1 and clause 20.
17-7
IEEE Std 1149.5-1995
~
Abort (16.2-1)
18. MTM-Bus Message Layer: Module Initialization and Self-Test (MIST) class commands (01 01 000-01 01111)
Reset Initialize ’lave Application Status (16.13.1) (1 6.3.1)
The Module Initialization and Self-Test (MIST) class commands are recommended commands that, if implemented, have to be implemented as described in table 18-1 to provide greater interoperability and interchangeability between modules. These commands provide a range of module initialization and self-test control. Each MIST class message has to be preceded immediately by an Enable Module Control (EMC) message or a Command Sequence Error will occur. The MIST class commands have been designated critical control commands (15.1.1; table 15-1) to offer added protection against an MTM-Bus message’s causing unintentional entry of a module into a self-test mode.
Reset Module Without
(18.3.1)
It is desirable to have both a command that causes all testing, initialization, etc., to occur and also to have a set of “building block” commands from which a particular ordered set of desired actions can be constructed. Table 18-1 provides a cross reference to the commands specified in this Standard that fill one or other of these roles.
Enable Disable Reset Module Module Module
With IBIT
(18.2.1) (”“”) (19.3.1) (192.1) I/O I/O
Table 18-1-Relationship and function of Core class, MIST class, and MlCT class commands use- ful in initialization, resetting, and self-testing of an S-module
Function
EMC required (table 15-1)
4. Reset module
initial state I 17. Full functional operation I
18. Enable outputs ____
Key:
Required commands
Core class -- -
Start (16.15.1)
X
Recommended commands
MIST class 1 MICT class -7 ___
“0;. indicates that the function in the left-most column is optional for the command in question. “x” indicates that the function in the left-most column is required for the command in question. “t” indicates that the action represented by that cell shall take place unless there is an active Disable Module command (19.2.1).
18-1
lEEE Std 1149.5-1995 lEEE STANDARD FOR MODULE TEST AND
18.1 General requirements for MIST commands
18.1.1 Specifications
(a) An S-module implementing the Reset Module With SBIT or the Module Initiated Built-In Test command shall be considered to implement self-test in the sense of 9.2. lc-e.
NOTE-If an S-module implements self-test, then the MFS and BSY bits of that S-modules Slave Status reg- ister are set prior to self-test initiation (9.2.1~) and remain set throughout the self-test (9.2.ld). Immediately following passage of a self-test, both the MFS and BSY bits of the S-module’s Slave Status register are cleared (9.2.le). If the S-module fails the self-test, then the BSY bit will be cleared (9.2.le).
(b) An S-module implementing a MIST class command that fails a self-test initiated by such a command shall leave the MFS bit of its Slave Status register set at the completion of that self-test.
NOTE-It is beyond the scope of this Standard to specify the operation of a self-testing procedure or the type of action@) required of an S-module (other than 18.l.lb) when a self-test fails.
(c) All MIST class commands described U 0 to be disabled (table 18-1) at the
cause the executing S-module’s module
(d) All MIST class S-module’s module I/O in which an executing
S-module has an ac
ommand” means that and has not executed maintain a record of
NOTE-9.4.le is a recommendation should provide a means accessible by completion without detection of a fau may indicate either that the self-test c some reason without having detected mitted to place such an indicator as a bit in the Bus Error register (9-3.E).
S-module implementing self-test (18.1. la) t would indicate whether self-test has run to failure is not set by a self-test procedure, it f failure or that the self-test terminated for s needed to resolve the ambiguity. It is per-
(f) In the execution of a MIST class commands, functions listed in column one of table 18-1 shall be performed in the order indicated by the numbering of the items in that column (beginning with “1”).
(g) Execution of a MIST class command shall not be construed to be completed until all implemented actions required, recommended, or permitted by this Standard have been completed.
18.2 Reset Module With Start-up Built-in Test (SBIT) command (01 01 000)
18.2.1 Specifications
(a) The message format of a Reset Module With SBIT command shall be as depicted in figure 18-1.
18-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
(b) Upon its S-Controller’s entering the EOM Slave Controller state at the termination of a Reset Module With SBIT message that has been immediately preceded by receipt of an EMC message, an S-module addressed by both these messages
(i) shall reset the S-module’s status registers as specified in 16.3.1~;
(ii) shall perform any other necessary reset of the S-module;
NOTE-Module VO is disabled (18.1.1~).
(iii) consequent to the actions described in 18.2.1b(i) and 18.2.1b(ii), shall execute the S-module’s module initialization and SBIT procedures.
NOTES
1 E r r o r handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.lb.
2-This Standard recommends (9.3.1 i. 9.1.1~) 111iiI ii hi1 iii llie Bus Error register or the Module Status register be set on completion of self-testing iiid IIiiiI 11iii1 1 ~ 1 alioiiltl 1~ designed to drive the logical OR feeding the EVO bit of the Slave Status register (9.2.1).
(c) Consequent to the actions specified in 18.2.lb, if the S-module passes module SBIT, an S-module executing the Reset Module With SBIT command shall force the S-module application circuitry to an initial state as defined by the S-module’s manufacturer’s documentation.
(d) Consequent to the action described in 18.2.lc, if an S-module executing the Reset Module With SBIT command does not implement recommendation 18.2.lf, the S-module shall wait in a stable mode as documented by that S-module’s manufacturer.
(e) The manufacturer of an S-module implementing the Reset Module With SBIT command shall doc- ument fully
(i) maximum time of execution of the command;
(ii) if permission 18.2.lg is implemented, the period within the time documented according to 18.2.le(i) that the S-module’s MTM-Bus interface will be inactive;
(iii) S-module actions should the SBIT activated by execution of this command fail.
Recommendations
(f) As part of the execution of the Reset Status with SBIT command and only after the S-module has passed module SBIT, an S-module should both
(i) enable the S-module’s module U0 (limited by 18.l.ld);
(ii) initiate full functional operation of the S-module.
NOTE-The advantage of implementing this recommendation is that it provides an easy mechanism by which completion of the self-testing initiated by the Reset Module With SBIT command can be detected. Namely, the M-module may transmit a Read Status command to the S-module in question and will only get a response if the S-module is back on-line subsequent to completion of self-testing.
18-3
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
Permissions
(g) During the execution of SBIT by an S-module, the MTM-Bus interface of that S-module may become inactive.
18.2.2 Description
The message format for the Reset Module With SBIT commands is shown in figure 18-1. The Reset Module With SBIT command has to be proceeded immediately by the EMC command.
An S-module may be designed to take its MTM-Bus interface off-line during the Reset Module With SBIT command for local testing of the interface circuitry. This means that the S-module might not receive com- mands sent during the self-testing period. If a given S-module implements permission 18.2.lg, the M-mod- ule may poll that S-module (e.g., via a Read Status command), requesting an ACKNOWLEDGE packet, to determine when an S-module is back on-line after execution of the Reset Module With SBIT command and ready to receive MTM-Bus commands.
NOTE-&/hen a F I I. . * ..- 1 1 --.- .. .. . I :' . I ;- broadcast or multicast, no S-module transmits anything (12.1.1d). However,normal? . : .. . .'. . : I . I itiated by of the same message will take place (l2.l.lf).
Figure 18-1-Singlecast message format for et Module With SBIT command
18.3 Reset Module Without SBIT command (0101001)
18.3.1 Specifications
(a) The message format of a Reset Module Without SBIT message shall be as depicted in figure 18-2.
(b) Upon its S-Controller's entering the EOM Slave Controller state at the termination of a Reset Module Without SBIT message immediately preceded by receipt of an EMC message, an S-module addressed by both these messages
(i) shall reset the S-module's status registers as specified in 16.3.1~;
(ii) shall perform any other necessary reset of the S-module;
(iii) shall bring the S-module to a known initial state as defined by S-module documentation.
18-4
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
NOTES
1-Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.lb.
2-At the onset of execution of this command-prior to the actions prescribed in 18.3.lb-the S-module’s module U0 is disabled (18.1.1~).
Recommendations
(c) As part of the execution of the Reset Status Without SBIT command, an S-module should both
(i) enable the S-module’s module I/O (limited by 18.l.ld);
(ii) initiate full functional operation of the S-module.
18.3.2 Description
The message format for the Reset Module Without SBIT commands is shown in figure 18-2. The Reset Module Without SBIT command has to be preceded immediately by the EMC command.
& __- HEADER
-1 This packet pair transfer is
NOTE-When a Rcscl Modi i l c Wilhout SBIT message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-modde processing that would he initiated by a singlecast of the same message will take place (12.1 .If).
Figure 18-2-Singlecast message format for the Reset Module Without SBIT command
18.4 Module Initiated Built-In Test (Module IBIT) command (0101010)
18.4.1 Specifications
(a) The message format of a Module BIT message shall be as defined in figure 18-3.
(b) Upon its S-Controller’s entering the EOM Slave Controller state at the termination of a Module IBIT message immediately preceded by receipt of a EMC message, an S-module addressed by both these messages
(i) shall reset the S-module’s status registers as described in 16.3.1~;
(ii) shall perform any other necessary reset of the S-module;
NOTE--The S-module will also disable its module U0 (18.1.1~) at the onset of this command-prior to actions listed in 18.4.lb.
18-5
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(iii) consequent to the actions of 18.4.1b(i), shall run the module BIT.
NOTES
1-Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.lb.
2-This Standard recommends (9.3.li; 9.4.le) that a bit in the Module status register be set on completion of self-testing and that that bit should be designed to drive the logical OR feeding the EVO bit of the Slave Status register (92.1).
(c) If the Module IBIT command, as implemented in a given S-module, can cause any of that S-module’s Module Status register bits or Additional Status register bits to change state, this shall be documented in the S-module’s manufacturer’s documentation.
(d) If recommendation 18.4. l h is implemented in a given S-module,
(i) recommendation 18.4.lg shall be implemented in that S-module;
(ii) both the actions specified in 18.4.lh shall be implemented and shall be performed in the order listed in 18.4.1 h.
ven S-module, then during execution of the d in 18.4. lg, if that S-module does not m a stable mode as documented by that
Module IBIT command and cons implement recommendation 18.4 S-module’s manufacturer.
ommand shall document fully
s outputs will be disabled if the S-module does not have an active Disable Module U0 command;
(iii) S-module actions should
(iv) S-module status and operati the S-module having passed permission 18.4.lh are imp1
Module IBIT command with recommendation 18.4. l g nor
Recommendations
(g) Consequent to the actions specified in 18.4.lb, if the S-module executing the Module IBIT command passes module IBIT, that S-module should force the S-module application circuitry to an initial state as defined by the S-module’s manufacturer’s documentation.
NOT-The initial state of 18.4.lg could be the same state that results from execution of the Initialize Appli- cation command (16.13.1).
(h) As part of the execution of the Module IBIT command and only after the S-module has passed module IBIT, an S-module should
(i) enable the S-module’s module U0 (limited by 18.l.ld);
(ii) initiate full functional operation of the S-module.
18-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
NOTE-An advantage of implementing this recommendation is that it provides an easy mechanism by which completion of the self-testing initiated by the Module IBIT command can be detected. Namely, the M-module may transmit a Read Status command to the S-module in question and will only get a response if the S-module is back on-line subsequent to completion of self-testing.
18.4.2 Description
The message format for the Module IBIT command is shown in figure 18-3. The Module IBIT command has to be preceded immediately by the EMC command.
HEADER 1 . ACKNOWLEDGE This packetpair transfer is e [ I optionai/(maymu~.
Aner an addressed S-module’s S-Controller entets its EOM Slave Controller state, the S-module is reset. Then that S-module’s outpus are dixbld; and IBITis initiated Module /BIT begins execution.
NOTE-When a Module IBlT message is broadcast or multicast, no S-module transmits anything (12.1.1d). However, nor- mal S-module processing that would be initiated by a singlecast of the same message will take place (12.1.1f).
Figure 18-3-Singlecast message format for the Module IBlT command
The Module IBIT command causes the S-module to be reset as defined in 16.3.lb prior to executing module DIT so that status changes following the Module IBIT command reflect the results of the self-test.
18.5 Reserved commands (01010114101111)
18.5.1 Specifications
Rules
(a) An S-module shall respond to any of the MIST class reserved commands in the manner specified for response to the Illegal command (16.17.1).
18.5.2 Description
The command codes 0101011-0101111 are reserved for future revisions of the MTM-Bus. They are not to be defined by the user. The command codes for user-defined commands are identified and specified in table 15-1 and clause 20.
18-7
IEEE Std 11 49.5-1 995
19. MTM-Bus Message Layer: Module VO Control and Test (MICT) class commands (01 10000-01 1011 1)
Module YO Control and Test (MICT) class commands are provided to standardize a mechanism for testing interconnections between modules. The first two commands, Disable Module I/O (19.2.1) and Enable Mod- ule I/O (19.3.1), are general purpose commands that have use beyond module interconnect testing (table 18-1). The remaining commands are specific to performing tests of backplane interconnects.
The model of non-MTM-Bus S-module VO that underlies the MICT class command definitions is defined by the following:
- Non-MTM-Bus S-module I/O includes signals that act as module outputs, signals that act as module inputs, and signals that can act as either module outputs or module inputs.
NOTEFrom this point forward in clause 19, the phrase “non-MTM-Bus S-module UO” is shortened to “S-module WO” or “module UO.” Likewise, references to particular types of non-MTM-Bus S-module U0 are made in the analogous shortened form.
- S-module signals operating as output signals may be controlled by an S-module internal signal that determines whether or not such a signal is driven or not.
- S-module bidirectional signals have their direction controlled by an S-module internal signal.
Further, the MICT class commands are based on a model of backplane interconnect testing that is a func- tional abstraction of boundary-scan (IEEE Std 1149.1). The MICT commands provide for
placing S-module outputs and S-module bidirectional signals acting as outputs in a non-driving state (Disable Module I/O command [ 19.2.13); controlling the direction of S-module bidirectional signals (Force Module Outputs command E19.4.11); defining values to be driven by S-module outputs and S-module bidirectional signals acting as out- puts (Force Module Outputs command [ 19.4.11, Sample Module With Force command [19.8.1]); establishing the set of values intended to be dri the backplane for test purposes while the sig- nals are in an undriven condition (Force Modu ts command [19.4.1]); actually driving such values onto the backplane and sampling resultant values on backplane nets (Force Module Outputs command [ 19.4.13, Enable Module VO command [ 19.3.13); using S-module input signals to sample the values on backplane nets (Sample Module I/O commands [19.5.1 through 19.8.11); returning an S-module to normal system operation (Release Module I/O command [19.9.1], Enable Module I/O command [ 19.3.11).
The Disable Module VO command is unusual among the commands defined in this Standard in that its hav- ing been issued to a given S-module has uninterrupted effect on that S-module until that S-module is addressed by a message conveying an Enable Module I/O command.
NOTE-If a question occurred as to whether a given S-module had an active Disable Module VO command, it could always be resolved by the sending of an Enable Module U 0 or a Disable Module U 0 command to that S-module. If for some reason (e.g., diagnosis of a fault condition) another method is required, a bit in an additional status register (9.518) could be used as an indicator of whether the module has an active Disable Module U 0 command or not.
Since all of the commands but the Release Module VO command, disrupt normal system operation, they are all considered critical control commands; and messages conveying them have to be preceded by an EMC message (table 15-1).
One approach to testing module interconnections via the MTM-Bus is as follows:
19-1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
1:
2:
3:
4:
5:
6:
Prior to issuing a MICT class command be sure that the S-modules to be addressed are not active system resources. (This is necessary since the MICT class commands can interfere with the opera- tional use of the modules.) Also, it is necessary to be sure that other S-modules will not use back- plane signals required for the interconnect test during that test. Disable outputs (using the Disable Module U0 command) of all modules that will be in r affected by, the intended testing (to ensure that there will be no conflicting values on 3-state signals). On each of the S-modules, set up the test values for the S-module signals that are to act as module outputs using the Force Module Outputs command. (This step provides known test data at the mod- ule output drivers.)
NOTE-Chip resources designed to support IEEE Std 1149.1 based testing of a module’s primary used to support intermodule interconnect testing.
Using the Enable Module U0 command, enable the outputs of the S-modules so that the test stimu- lus is applied to the backplane interconnect. Capture the values propagated through the backplane at S-module inputs using one of Module Inputs commands. Repeat steps 2 through 5 as necessary to apply all interconnection test patterns.
To restore modules to the system, follow steps 7 through 10:
7:
8:
9:
10:
Disable outputs of all modules that were involved in, or affected by, the testing using the Disable Module I/O command. Release control of the module J/O control signds and module output values to the module functional circuitry using the Release Motlulc 1 / 0 command. Restore the module’s functional circuitry to the desired system state using appropriate MTM-Bus commands (e.g., Initialize Application, Reset Module with SBIT, Reset Module Without SBIT). Restore the module I/O to the system functionality using the Enable Module I/O command.
The commands described in this Standard are not defined based on any assumptions concerning hardware implementation. Hardware implementations similar to that s@fied for chips in JEEE Std 1149.1 could be used. Another option would be the use of on-module software.
19.1 MICT class commands-general requirements
Rules
(a) The purpose of the MICT class commands shall be to provide the ability to verify backplane (inter- module) interconnect by means of
(i) application of test vectors via predetermined sets of S-module signals operating as module outputs;
(ii) sampling of values on backplane interconnect at S-module signals operating as module inputs.
NOTE--All MICT class commands defined in this Standard, with the exception of the Release Module U 0 command, have to be conveyed in messages that are immediately preceded by an EMC message (table 15-1).
(b) The following signals shall be called MICT-testable module signals:
(i) module I/O signals that are instrumented to drive test data onto a backplane signal path under control of MICT class commands;
19-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(ii) S-module U 0 signals that are instrumented to sample data from a backplane signal path under control of MICT class commands;
(iii) S-module output enable control signals instrumented to drive test data under control of MICT class commands;
(iv) S-module bidirectional signal direction control signals instrumented to drive test data under control of MICT class commands.
(c) No signal of the MTM-Bus shall be a MICT-testable signal.
(d) For any S-module implementing MICT class commands, the manufacturer of that S-module shall define for every module U0 signal, module output enable control signal, and module bidirectional signal direction control signal,
(i) whether or not such a signal is MICT-testable;
(ii) if it is MICT-testable, to which of the classes defined in 19.1. l b that signal belongs;
(iii) whether it may drive on-module circuitry during MICT class command based testing and, if so, to what effect.
(e) For any S-module that implements MICT class commands, that S-module’s manufacturer’s docu- mentation shall explicitly state the relationship between the MICT-testable module signals of that S- module and the bit positions within DATA packets used to write input test vectors or to read output (result) test vectors during MICT class messages.
(f) An S-module’s manufacturer’s documentation shall indicate for each MICT-testable signal that may operate as an output whether that signal is a 2-state output, 3-state output, or bidirectional signal.
(g) If a MICT-testable module U 0 signal may operate as an output, any output enable control signal or direction control signal for that MICT-testable mo U0 signal shall also be MICT-testable.
(h) In the manufacturer supplied documentation for an S-module implementing MICT class commands, each MICT-testable output enable control signal (C) or MICT-testable bidirectional signal direction control signal (0) shall be mapped to the S-module U 0 signal(s) controlled by C (0).
(i) In a bit string of data read or written by a MICT class command, if the value of a given MICT- testable signal is represented by more than one bit, the set of all such bits for that signal shall be con- tiguous in that bit string.
NOTEcThe situation in which multiple.bits would represent a signal value could arise if that value were rep- resented by an ASCII character or a hexadecimal digit.
(j) If, for a given set of MICT-testable module I/O signals, the following both hold:
(i) all module U 0 signals in the set may operate as module outputs;
(ii) in the normal (non-test) operation of the S-module in question, when any of the module U 0 signals in the set operates as a module output, they all do SO;
then there shall be a single MICT-testable module output enable control signal or (as appropriate to the U0 signals in question) a single MICT-testable module bidirectional signal direction control sig- nal, S,
19-3
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(iii) that alone serves to enable all module I/O signals in the set to operate as module outputs;
(iv) that alone serves to disable output operation of all module I/O signals in the set;
(v) that for a given value of S, either enables all module I/O signals in the set to operate as module outputs or disables output operation of all module U0 signals in the set.
(k) The time required for each MICT class command to complete execution shall be noted in the module documentation.
(1) During MICT-based backplane testing, the internal logic of any S-module executing MICT class commands shall not react to the MICT test input data in any manner interfering with the testing.
(m) In a given S-module, if any command is implemented in such a way that it may leave the module I/ 0 of that S-module disabled after the execution of some command, then the Enable Module U0 command (19.3) shall be implemented in that S-module.
NOTE--In a given S-module, if the Disable Module U0 command is implemented, the Enable Module U0 command has to be implemented in that S-module.
In a given S-module, if Force command (19.8) is mented in that S-module.
mmand (19.4) or the Sample Module With Module I/O command (19.9) shall be imple-
19.1.2 Description
An S-module implementing any MI s command will fully document its operation including the set of S-module outputs controlled, the set of S-module inputs sampled, and specifics of the command’s message format that are not fixed by this Standard.
19.2 Disable Module I/O command (0110
19.2.1 Specifications
Rules
The message format of a Disable Module I/O message shall be as depicted in figure 19-1.
An addressed S-module receiving a Disable Module U0 message immediately preceded by an EMC message, shall disable all module I/O drivers/transmitter/transformers.
NOTES
1-Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1 b.
2-The term “module UO” has been defined to exclude MTM-Bus signals (introduction to clause 19).
Execution of the Disable Module U 0 command shall not be construed to be concluded until all module VO of an S-module executing the command are fully disabled.
NOTEcThe important consequence of this rule is that the BSY bit of an S-module’s Slave Status register becomes an indicator for the complete disabling of the S-module’s module UO.
MAINTENANCE BUS (MTM-BUS) PROTOCOL
HEADER
IEEE Std 1149.5-1995
_____)
(d) Once an S-module has executed the Disable Module U0 command, those drivers/transmitters/trans- formers disabled by execution of the command (19.2.lb) shall remain disabled until the S-module executes the Enable Module U 0 command (19.3).
(e) An S-module that has executed the Disable Module VO command and has not subsequently exe- cuted the Enable Module U0 command (19.3) shall be said to “have an active Disable Module U0 command.”
NOTE-’”aving an active Disable Module U0 command” has absolute precedence over all other commands related to S-module UO-except for the Enable Module U0 command.
(f) When disabling module output signals in response to this command, these outputs have to be forced to an inactive state or a non-controlling (safe) value.
(g) For any given S-module, the value of output signals when disabled by this command shall be docu- mented by that S-module’s manufacturer.
Permissions
(h) When disabling module output signals in response to this command, module input signals may be blocked from affecting S-module circuitry.
19.2.2 Description
This command is a general-purpose command that provides a global non-MTM-Bus module VO disable. In addition to supporting S-module self-test and module interconnect testing, it provides a useful capability to quickly take an S-module off a backplane bus when that S-module is believed to be responsible for bus fail- ure or some other failure that is difficult to isolate. It is also useful for taking S-modules off-line in support of module sparing and fault-tolerance strategies.
The message format for the Disable Module V command has to be preceded immediately by
Implementing this command as a single command (rather than a series of other MTM bus commands) is strongly recommended. This command can be used in broadcast or multicast mode to quickly regain control of a group of suspected faulty (e.g., babbling) S-modules. For quickly disabling a group of S-modules, it would be less efficient (and perhaps inadequate) if a series of module-unique MTM-Bus commands had to be issued by the M-module to take the S-modules off-line.
and is shown in figure 19-1. The Disable Module U 0 le Control command.
Module YO dkabled
NOTE-When a Disable Module I10 message is broadcast or multicast, no S-module transmits anything (12.1 .Id). Howl er, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1 .lo.
Figure 19-l-Singlecast message format for a Disable Module U 0 message
19-5
IEEE Std 11 49.5-1 995
HEADER
IEEE STANDARD FOR MODULE TEST AND
.
19.3 Enable Module VO command (0110001)
19.3.1 Specifications
The message format of an Enable Module U0 message shall be as depicted in figure 19-2.
An addressed S-module receiving an Enable Module U0 message that has been immediately pre- ceded by an EMC message, shall
(9
(ii)
enable any module U0 d r i v e r s / t r a n s m i t s f o r m e r that is not currently disabled by non- MTM-Bus function@) of that S-module;
return to normal operation any module input that is not Mocked from affecting S-module cir- cuitry by non-MTM-Bus function(s) of that S-module;
NOTE-Error handling in the case in which the necessary EMC message does not precede a critical con- trol message is described in 11.9.lb.
An S-module that has executed an Enable Module I/O command shall not have an active Disable Module I/O command;
Execution of the Enable Module I/O command shall not be construed to be concluded until all module U0 of an S-module executing the command are fully enabled;
NOTE-The BSY bit of the Slave Status register (9.2.la; table 9-1) will be set when an Enable Module U 0 command begins to execute and will not be cleared until all module I/O of an S-module executing the com- mand are fully enabled.
19.3.2 Description
This command is a general-purpose command that provides a global module I/O enable. It restores control of the module’s I/O to the functional output enable control signals internal to the S-module (reversing the override action created by the Disable Module YO command). In addition to supporting module self-test and module interconnect testing, it provides a useful capability (in combination with the Release Module U 0 command r19.9.11) to quickly restore S-modules (e.g.9 as a group) to “normal” functional control of module UO. It is also useful for bringing modules on-line in support of module sparing and fault-tolerance strategies.
The message format for the Enable Module U 0 command is shown in figure 19-2. An Enable Module U 0 message has to be preceded immediately by an EMC message.
As in the case of the Disable Module U0 command (19.2.2), implementing this command as a single com- mand (rather than a series of other MTM-Bus commands) is strongly recommended.
This packetpair transfer is opfiond 7 1 = I ACKNOWLEDGE I (mauoQcu,j~
Module YO enabled
NOTE-When an Enable Module I/O message is broadcast or multicast, no S-module transmits anything (12.1.1d). How- ever, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1 .If).
Figure 19-2-Singlecast message format for an Enable Module VO message
19-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
19.4 Force Module Outputs command (0110010)
19.4.1 Specifications
(a) The message format of a Force Module Outputs message shall be as depicted in figure 19-3.
NOTE-The text of figure 19-3 is incorporated as part of 19.4.la.
(b) The M-module DATA packets of a Force Module Outputs message shall contain test pattern data to be applied to MICT-testable signals of the addressed S-module(s).
NOTE-The test data to be applied as a result of execution of the Force Module Outputs command can be pro- vided previously in some other manner (figure 19-3).
(c) An S-module’s manufacturer’s documentation shall specify
(i) the number of DATA packets needed to transfer a single output test vector to the MICT-testable signals of the S-module via a Force Module Outputs message;
(ii) the format and contents of such DATA packets.
(d) An addressed S-module
(i) not having an active Disable Module I/O command (19.2.1) and
(ii) receiving a Force Module Outputs message immediately preceded by an EMC message addressed to that S-module
shall
(iii) cause S-module functional control of MICT-testable signals to be overridden until the S - module next executes the Release Modulc I/O command (19.9.1);
(iv) force the S-module’s module output enable control signals, module bidirectional signal direction control signals, and module output signals to values indicated by the test pattern DATA packets of the current message (19.4. IC).
NOTE-Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1 b.
(e) An addressed S-module
(i) having an active Disable Module U 0 command (19.2.1) and
(ii) receiving a Force Module Outputs message immediately preceded by an EMC message addressed to that S-module
shall
(iii) cause S-module functional control of MICT-testable signals to be overridden until the S- module next executes the Release Module UO command (19.9.1);
(iv) preserve the test data transmitted until the S-module next executes the Release Module I/O command (19.9.1) or the Sample Module With Force command (19.8.1) or again executes the Force Module Outputs command;
19-7
IEEE Std 1149.5-1995 IEEE STANDARD FQR MODULE TEST AND
(v) preserve the test data transmitted in such a manner that, barring intervening execution of com- mands listed in 19.4.le(iv), the S-module can force the test pattern data onto its module outputs after executing an Enable Module YO (19.3.1) command.
NOTES
1-Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.lb.
2-The Release Module U 0 command returns module U0 to full functional operation and test data that has not been forced on module outputs prior to the execution of the Release Module U0 command becomes irrelevant.
(f) Execution of the Force Module Outputs command by an S-module shall not be construed to be com- pleted until all the S-module’s module output enable control signals, module bidirectional signal direction control signals, and module output signals are set to the values indicated by the test pattern DATA packets transmitted in the current message.
NOTGThe BSY bit of the Slave Status register (9.2.la; table 9-1) will be set when a Force Module Outputs command begins to execute and will not be cleared until all the S-module’s module output enable control sig- nals, module bidirectional signal direction control signals, and module output signals are set to the values indi- cated by the test pattern DATA packets transmitted in the current message.
19.4.2 Description
The Force Module Outputs command is used to directly control the values on the S-module’s outputs to sim- plify module interconnect testing. Such control of module U0 is mutually exclusive with “normal” func- tional control of the same I/O.
The message format for the Force Module Outputs command is shown in figure 19-3. A Force Module Out- puts message has to be preceded immediately by an EMC message.
M-MODULE S-MODULE
~ACKETCOUNT 1 .-
____) 7 MDATA 1
This packetpair transfer is options/ (mayomud.
NULL I \ NULL
____) MDATA 3 . NULL . .
7he Force Modu/e Ouputs command mayormaynotsupp& the test data to be appled at S-module ouputs. When the test values to be appfled are pro- videdin the same message as is the commmand, the entire message fonnat i/ustratedsha// be used Othenvise, on& the pon‘ion of the message format above this fine &all be used
NOTE-When a Force Module Outputs message is broadcast or multicast, no S-module transmits anything (12.1.1d) on the MTM-Bus. However, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1.1f).
Figure 19-3-Singlecast message format for a Force Module Outputs message
19-8
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
Once received by an addressed S-module, the test pattern data from a Force Module Outputs message shall remain stored on the S-module until a Release Module I/O command (19.9. l), another Force Module Out- puts command, or a Sample Module With Force command (19.8.1) is executed. The sourcing of test pattern data delivered to an S-module via a Force Module Outputs message to (an)other module(s) is controlled by the Disable Module I/O (19.2.1) and Enable Module I/O (19.3.1) commands.
NOTE-In applications requiring the most secure approach, a Force Module Outputs message should be preceded by a Disable Module U0 message to prevent negative impact on the system caused by transient values on S-module outputs that might occur while output values are being established.
The BSY bit will be cleared when the values to be forced are available to the module outputs. (The outputs may not drive the values at that time if they have been disabled by use of the Disable Module I/O command [19.2.1].)
It is recommended that one or all of the three Sample Module Inputs commands defined by this Standard be implemented. The three commands are Sample Module No Change (OllOOll), Sample Module Don’t Care (OllOlOO), and Sample Module With Force (0110101). They are treated in 19.6 through 19.8, respectively.
Execution of the Sample Module No Change command causes S-module inputs to be sampled and the sam- pled data to be sent back to the M-module, but the S-module’s actively driven output values may change during the time sampled data is being transmitted to the M-module (not while actual sampling is going on) and may result in unpredictable values being forced on module I/O control signals and module outputs when command execution completes.
Execution of the Sample Module With Force command C;ILISCS nioclule inputs’ current values to be sampled. The M-module then transmits DATA packets to the S-inoclule conliiinine new test data values (as in the Force Module Outputs command 119.4.11) while the just snmplccl lest result values are being transmitted from the S-module to the M-module.
During execution of the Sample Module Don’t Care comm constrained in any way.
, the values on the S-module’s outputs are not
In the case of the Sample Module With Force command, there is an option to disable module I/O in a similar manner; the module I/O cannot be left disabled at the conclusion of the execution of that command.
The message formats for the Sample Module I/O messages are as shown in figure 19-4 and figure 19-5. Both commands are classified as critical control commands.
NOTE-The sourcing of data by an S-module executing a Sample Module Inputs command is controlled by whether or not that S-module has an active Disable Module YO command. This is to be distinguished from any requirement that, if values are being driven, they are to be held stable during some period.
19.5.1 Specifications
Rules
(a) For an S-module implementing a Sample Module Inputs command, that S-module’s manufacturer’s documentation shall specify
(i) the number of DATA packets needed to transfer a single output test vector to the MICT-testable signals of the S-module via a Sample Module Inputs message;
19-9
lEEE Std 1149.5-1995 lEEE STANDARD FOR MODULE TEST AND
(ii) the format and contents of such DATApackets (19.5.la(i));
(iii) the number of DATA packets needed to transfer a single test result (samplcd data) vector from the S-module to the M-module;
(iv) the format and content of such DATApackets (19.5.1a(iii));
(v) the maximum length of the period in which data sampling (19.5.1b(i)) occurs.
Upon receiving a Sample Module Inputs message immediately preceded by an EMC message, an S- module addressed by both these messages shall
(ii)
(iii)
sample the current values of that S-module’s input signals within a period that shall be called the “sampling period” and shall be initiated by the S-module after its S-Controller has entered its PAUSE Slave Controller state following the transmission of the HEADER packet of the current message (if the Acknowledge Request bit is not set in that packet) or after the trans- mission of the PACKJ3T COUNT packet (otherwise);
NOTE-The importance of 19.5.la(v) becomes elear here. The M-module has to take count of the time that the S-module requires for sampling-by not causing a state transition in the S-module’s S-Controller until sampling is over.
maintain stable values on all module outputs during the sampling period (19.5.1b(i));
subsequent to the action of 19.5.1b(i), transmit the sampled values (test result data) to the M- module or store them to be recovered in some other manner.
NOTES
1-Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1 b.
2-Figures 19-4 and 19-5 provide that test d ot be”transmitted as part of a Sample Module Inputs message.
Execution of a Sample Module Inputs command shall not be construed to be completed until
(i) values on module inputs have been sampled;
(ii) these values (19.5.1a(iii); 19.5.la(iv); 19.5.1c(i)) have been transmitted to the M-module;
(iii) any new test input values (19.5.1a(i); 19.5.1a(ii)) have reached steady state on the appropriate MICT-testable signals of the S-module.
NOTES
1-It is a consequence of these requirements that any given singlecast Sample Module Inputs message involves transmission of one test vector’s worth of sampled data to the M-module. Likewise, any given Sample Module Inputs message involves the transmission of, at most, one test vector’s worth of new test input data to the addressed S-module( s) . 2-The BSY bit of the Slave Status register (9.2.la; table 9-1) will be set when a Sample Module Inputs command begins to execute and will not be cleared until al l three criteria listed in 19.5.1~ are met.
Recommendations
(d) S-modules that implement Module Znterconnect Testing should implement at least one of the three Sample Module Inputs commands defined in 19.6.1 through 19.8.1.
19-10
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
19.6 Sample Module No Change command (0110011)
19.6.1 Specifications
(a) The format of a Sample Module No Change command shall be as depicted in figure 19-4.
NOTE-The text of figure 19-4 is incorporated as part of 19.6.la.
(b) An addressed S-module’s output values shall remain stable during execution of the Sample Module No Change command.
(c) During a Sample Module No Change message, the M-module shall transmit NULL packets (figure 19-4) in sufficient quantity (19.5.1a(iii)) to allow transmission by an addressed S-module of all sampled data.
M-MODULE S-MODULE
L EADEI -I -- - + . - - J
- - - _ - + p,,KNOWLEDGEj This packet pair transfer is optional _ _ (may occur). 1 PACKETCOUNT ! 2:- -
not recover test result data. When test _ _ + result data are transmitted in the same 4 - - message as is the command, the en-
tire message format illustrated shall be used. Othemise, only the portion of
f. - _ I SDATA ; the message format above this line shall be used.
r <DATA 2 -- J - . ._ - -_ + - -
. ____j. * - - m’
NOTE-When a Sample Module No Change message or a Sample Module Don’t Care message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1.lf).
Figure 19-&Singlecast message format for a Sample Module No Change message or a Sample Module Don’t Care message
19.7 Sample Module Don’t Care command (01 101 00)
19.7.1 Specifications
(a) The format of a Sample Module Don’t Care message shall be as depicted in figure 19-4.
NOTE-The text of figure 19-4 is incorporated as part of 19.7.la.
19-11
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(b) During execution of the Sample Module Don’t Care command by a given S-module, the values of module outputs of that S-module are not constrained in any way as long as the S-module does not have an active Disable Module I/O command.
(c) During a Sample Module Don’t Care message, the M-module shall transmit NULL packets (figure 19-4) in sufficient quantity (19.5.1a(iii)) to allow transmission by an addressed S-module of all sampled data.
19.8 Sample Module With Force command (0110101)
19.8.1 Specifications
(a) The format of a Sample Module With Force message shall be as depicted in figure 19-5.
NOTE-The text of figure 19-5 is incorporated as part of 19.8.la.
M-MODULE S-MODULE
- ___ I F ~ ~ ~ ~ ~ ~ T ~ ~ I J ~- - -& ACKNOwLEDGg This packet pair transfer is optional L _ - - LA.__ ~ (may occur).
Force DATA 3
. . .
- Sample Module With Force messag- es may or may not include the trans- mission of test data. When test data are transmitted in the same message as is the command, the entire mes- sage format illustrated shall be used. Otherwise, only the portion of the message format above this line shall
I Sample DATA J -
a be used.
NOTE-When a Sample Module With Force message is broadcast or multicast, no S-module transmits anything (12.1 .Id). However, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1 .If).
Figure 19-5-Singlecast message format for a Sample Module With Force message
(b) During a singlecast Sample Module With Force message immediately preceded by an EMC message, the MTM-Bus M-module shall transmit new force data values to an addressed S-module while that S-module transmits the values sampled during the sample interval to the M-module as detailed in figure 19-5. The S-module shall source the new force data values onto the module outputs upon the S-module’s S-Controller’s entry into its EOM Slave Controller state at the end transmission of the Sample Module With Force message.
(c) During receipt of a Sample Module With Force message immediately preceded by an EMC message, an S-module addressed by both these messages
19-12
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
(i) shall cause S-module functional control of MICT-testable signals to be overridden until the S- module next executes the Release Module UO command (19.9.1);
(ii) unless permission 19.8.lf is implemented in that S-module, shall maintain the values on module outputs constant throughout the message until the later of two events-(l) the newly supplied test input values are stable and ready to be forced onto the module output signals or (2) the addressed S-module’s S-Controller enters its EOM Slave Controller state.
(d) In an S-module implementing permission 19.8.lf, the S-module outputs have to be enabled as soon as possible after the condition of 19.8.lc(i) is achieved.
(e) Execution of the Sample Module With Force command shall not be construed to be completed until the conditions of 19.8.1~ are fully achieved and (if the S-module implements permission 19.8.10 the requirement of 19.8.ld is fully met.
Permissions
(f) Module outputs of an addressed S-module may be disabled while sampled data is being transmitted to the M-module and while the condition of 19.8.lc(i) has not yet been achieved.
19.9 Release Module WO command (0110110)
19.9.1 Specifications
Rules
(a) The message format of the Release Module U0 command shall be as depicted in figure 19-6.
(b) Upon receipt of a Release Module U0 message,
(i) shall release control of the module I/O control signals formally required by execution of a Force Module Outputs command (19.4.1) or a Sample Module With Force command (19.8.1) with the result of returning module output values to the control of S-module functional (non-test) circuitry;
(ii) if that S-module has an active Disable Module I/O command (19.2.1)’ shall not enable module UO.
(c) Execution of the Release Module I/O command shall not be construed to be complete until an addressed S-module’s module I/O is fully returned to functional control.
NOTE-The BSY bit of the Slave Status register (9.2.la; table 9-1) will be set when a Release Module IIO command begins to execute and will not be cleared until an addressed S-module’s module YO is fully returned to functional control.
19.9.2 Description
The message format for the Release Module U0 command is shown in figure 19-6.
19-13
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
I HEADER I
I PACKETCOUNT I ACKNOWLEDGE Thispacketpair transfer is optiond - (mayomuo.
NOTE-When a Release Module 810 message is broadcast or tnUMSt, IX) S-module transmits anything (12.1.1d). How- ever, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1 .If).
Figure 19-6-Singtecast message format for a Release Module VO command
The Release Module U0 command is used to return all S-module circuitry that was under control of the test pattern data [as a result of execution of the Force Module Outputs (19.4.1) command or the Sample Module With Force command (19.8. l)] to functional control. If an S-module that has executed the Release Module I/ 0 command has an active Disable Module I/O command (19.2.1), the outputs will remain disabled until an Enable Module I/O command (19.3.1) is executed.
19.10 Reserved commands (0110111
19.10.1 Specifications
Rules
(a) An S-module shall respond to any of the MTCT cl for response to the Illegal command (16.17.1).
commands in the manner specified
19.10.2 Description
The reserved commands 0110111-1001111 are reserved for future revisions of the MTM-Bus. They are not to be defined by the user. The command codes for user-defined commands are identified and specified in table 15-1 and clause 20.
19-14
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
20. MTM-Bus Message Layer: Standard Extension class commands (1 01 0000-1 01 11 11) and User-Defined class commands (1100000-1111110)
20.1 Standard Extension class commands (1010000-1011111)
20.1.1 Specifications
(a) The Standard Extension commands (having command codes 1010000-1011111) shall be reserved for the use of standards-making bodies.
(b) If an S-module receives a message containing a command code of a Standard Extension command that is either
(i) not defined by any standards-making body or
(ii) not implemented in that S-module,
that S-module shall respond as required by the Illegal command (16.17.1).
(c) Assignment of command codes 1010000-1011111 shall be administered by the IEEE Standards Office (Piscataway, New Jersey) or an organization to which the IEEE Standards Office delegates this authority.
Recommendations
(d) Standard Extension commands that may cause undesirable S-module side effects if they are not properly used should be protected against accidental use.
NOTE--Such protection might be provided by means e Enable Module Control (16.10.1) command.
20.1.2 Description
This set of command codes is reserved so that standards making bodies other than the IEEE may have a set of command codes to be used for their own needs.
20.2 User-Defined class commands (1100000-1111110)
20.2.1 Specifications
(a) The User-Defined commands (1 lO00Oelll 11 10) shall operate as defined by the user.
(b) If the user has not defined these commands or a subset of these commands, the undefined commands shall have S-module response as specified for the Illegal command (16.17.1).
(e) All User-Defined commands shall be designated as “public” or “private” commands.
(d) The command codes and operation of all User-Defined public commands shall be fully documented.
20- 1
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(e) The command codes for User-Defined private commands shall be documented.
Recommendations
(f) User-defined private commands that may cause undesirable S-module side-effects if they are not properly used should be protected against accidental use.
NOTEcSuch protection could take any of a number of forms including using the Enable Module Control command (16.10.1).
20.2.2 Description
The command codes 1100000-1111110 are available for definition by the user. If they are not defined, then they have to be treated as illegal commands.
User-defined commands can be grouped into two types: public and private. Public commands may be used to access special features of the module and are fully documented as their function, results and data trans- ferred. Private commands may be used by the manufacturer for testing or debug and may cause unpredict- able S-module behavior if not used in the correct environments. The only requirement for private commands is to document their command codes. Private commands should be protected against accidental use in cases where module damage may occur if rrect environment or at an inappro- priate time. This protection could be by means f a number of methods including using the Enable Module Control command (16.10.1).
20-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
port type
Fault logs
Test Data Storage ~~-
IEEE Std 11 49.5-1 995
Specification
Recommended (21.3)
Permitted (21.4)
21. Data transfer ports
Access to IEEE Std 1149.1 bus(es)
Access to other module buses
The Data Transfer class commands described in clause 17 are useful for providing access to a wide variety of on-module functions including status registers, fault logs, on-module memory, and on-module buses. The present clause standardizes the use of a number of port addresses and establishes requirements for module- specific ports.
Recommended when such buses are present (21.10 through 2 1.12)
Permitted
21.1 Data transfer ports-general requirements
Reserved for future definition
Reserved for use of other standards bodies
User-defined
21.1.1 Specifications
&&
(a) Each data transfer port within an S-module shall be identified by a 16-bit port identifier (17.1.1).
Reserved
Reserved
Permitted
Table 21 -1-Reserved port identifiers for Data Transfer class commands
Port identifier I* OOOB
OOOC OOOD OoOE400F
0 0 1 W l F
0020-007F
0080
0081-0FOO
OFOl-OFFF
1OOO-FFFF
ErrorKtatus registers Slave Status register Bus Error register Module Status register Additional Status registers
Recommended (21.5)
. .
ID registers Recommended Manufacturer ID port (21.6) Module Manufacturer port (21.7) User Identification ports (21.8)
Access to status register backup means I Recommended (9.l.ld; 21.9) I
NOTE-Some port types may not support all of the Data Transfer class commands.
(b) Port identifiers ‘0000’ HEX through ‘OFFF’ HEX shall be reserved for specific port types precisely as shown in table 21-1 and as follows:
(i) Assignment of Port identifiers ‘0081’ HEX through ‘OF00’ HEX shall be made as required by future supplements to, or revisions of, this Standard.
21-1
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(ii) Assignment of Port identifiers ‘OFo1’ HEX through ‘ O W HEX for use by other standards bodies shall be administered by the working group maintaining this Standard.
(c) If a port type listed in the second column (“Initial controller state”) of table 21-1 is implemented, its port identifier(s) shall lie within the associated port identifier range indicated in that table.
(d) If in any Data Transfer class message the message is terminated after a port is selected and prior to transmission of the first packet pair of the port-specific part of the message (17.1.1~; figure 17-l), the selected port shall report an error (11.8.1).
(e) Manufacturer provided documentation of an S-module shall identify all supported port identifiers.
NOTE-Further documentation requirements for implemented ports are described in 21.2.
Recommendations
(f) S-modules should provide access to one or more ModuleEault Log ports, as specified in 21.3.
( g ) S-modules should provide access (as specified in 21.5) to the Slave Status register, Bus Error reg- ister, Module Status register, and additional status register ports.
(h) S-modules should provide acce
(i) When one or more instances of should provide access to such buses via ports as specified in 21.10 through 21.12.
(i) If an S-module provides data backup means as recommended in 9.l.ld, that S-module should provide access to these backup means via an access to the status register backup means-Error/ Status Shadow register port as specified in 21.9.
as specified in 21.6 through 21.8.
ent on an S-module, that S-module
Permissions
(k) S-modules may provide access to Test D
(1) S-modules may provide access to ports for module buses.
(m) S-modules may provide access to additional user-defined ports.
(n) A port may provide access via logical or physical addressing to an individual register or memory.
(0) Selection of a port may activate processing of data written to that port and may generate response data to be read from that port.
(p) Multiple ports may be used to access a single module function (e.g., to access an on-module bus, ports could be provided for control, status, and data).
(9) Port addressing may be defined for a module so that access to multiple port addresses provide the same function.)
21.1.2 Description
The Data Transfer class commands described in clause 17 allow read, write, and readwrite access to ports within S-modules. These ports are identified by a 16-bit port identifier that is provided in the PORT ID packet of a Data Transfer class message.
21-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
A data transfer port can be used to provide access to a variety of on-module resources. An individual port identifier (port ID) may provide access to an individual register, memory, or even an on-module bus. Table 21-1 lists the standardized port identifiers. Standardized port IDS are provided to ModulelFault Logs, Error/ Status registers, and Identification registers. The format of data transfers to these standardized ports are defined in the following clauses.
No port will remain selected after the termination of a message (17.1. Id).
21.2 Port definition and documentation requirements
21.2.1 Specifications
(a) The definition of a port shall completely specify the port-specific message format including the number and position of S-module transmitted NULL packets and any packets containing address, data, supported Data Transfer class commands, error detection codes (e.g., CRC), status, control, or other information.
(b) For ports that support the Reamri te command,
(i) the packet latency of returning data shall be specified;
(ii) any order dependency of reading and writing shall be specified.
(c) The definition of a port shall identify typical and maximum number of cycles of the MCLK signal in which the M-Controller may be required to remain in its PAUSE-01 Master Controller state between packets within a message selecting the port.
21.2.2 Description
Each port that is supported by an S-module has to be documented to ensure that it may be accessed appropri- ately by the M-module. The definition of a port may be viewed as a programmer’s model of the port. Packet latency is further detailed in 17.4.2 and figure 17-4.
It is important that the number and position of S-module transmitted NULL packets be documented. For example, there may be NULL packets transmitted at the outset of the port-specific part of a Data Transfer class message because the operation of selecting a given port or a function receiving data via a selected port may be time-consuming. At other times, S-module transmission of NULL packets may be a reflection of packet latency; or such transmission may be required at sub-message boundaries to allow completion of some function in the S-module.
(a) A ModuleFault Log port shall provide access to non-volatile readwrite memory.
(b) A ModuleFault Log port shall support the Read Data and Write Data commands.
21-3
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
NOTE-Attempting to access ports having port identifiers ‘oo00’ HEX through ‘0003’ HEX using the Data Transfer class Reserved command (17.5.1) will cause the ILC bit in the Bus Error register to be set (11.10.1). Attempting to access ports having port identifiers ‘0000’ HEX through ‘0003’ HEX using any Data Transfer class command not supported by the selected port (21.2.la) will cause the PTE bit in the Bus Error register to be set (11.8.1f).
(c) If permission 21.3.Bd is implemented in a given S-module, then the read action shall precede the write action.
Permissions
(d) A ModuleFault Log port may support the Read/Write Data command.
21.3.2 Description
Typically, a ModuleFault Log is implemented as non-volatile memory and is used for the storage of module-specific data including test patterns, test signatures, and fault log data.
21.4 Test Data Storage ports (‘0004’ HEX - ‘0007’ HEX)
21.4.1 Specifications
(a) A Test Data Storage port shall provide latile readwrite memory.
(b) A Test Data Storage port shall support the Read Data and Write Data commands.
NOTE--Attempting to acccss p Transfer class Reserved coininil Attempting to access ports Ili lViilg port ic Data Transfer class comrii;iiid no1 supporl Error register to be set (11.8.1f).
(c) If permission 21.4.ld is imp
‘0007’ HEX with any Data r register to be set (11.10.1).
’ HEX through ‘0007’ HEX using any user-defined ted port (21.2.la) will cause the PTE bit in the Bus
le, then the read action shall precede the write action.
Permissions
(d) A Test Data Storage port may support the Reamr i t e Data command.
21.4.2 Description
A Test Data Storage port is typically used to gain access to memory in which module-specific test data are stored on the S-module. Such data could include good signature data, shift register seed values, test vectors, microcode for self-tests of module function, etc. Implementing and using such a port reduces the need for a system-level test controller to be programmed to know testing details of individual modules or to have mem- ory in which to store all data for testing all modules. This makes it easier to develop a system-level test strat- egy that is closer to “plug and play” than would be possible otherwise-a new S-module can be tested in a system without needing system-level test (even test and diagnostic) program updating.
(a) An ErrorIStatus register port shall support the Read Data and Write Data commands.
NOTE-Attempting to access ports with port identifiers ‘0008’ HEX through ‘000B’ HEX with any Data Transfer class Reserved command (17.5.1) will cause the L C bit in the Bus Error register to be set (11.10.1). Attempting to access ports having port identifiers ‘0008’ HEX through ‘OOOB’ HEX using any other Data Transfer class command not supported by the selected port (21.2.la) will cause the PTE bit in the Bus Error register to be set (11.8.1f).
(b) Accessing Slave Status register, Bus Error register, and Module Status register ports (Port ID’s ‘0008’ HEX through ‘OOOA’ HEX) using a singlecast Read Data message shall not change the values in the registers.
NOTE-The BMR bit (bit <lo>) of the Bus Error register (9.3.1; table 9-4) may have its value changed by a broadcast or multicast Read Data message selecting an Error/Status register port.
(c) If multiple S-module status registers are accessed via one Error/Status register port, interpretation of the data returned shall be detailed in the S-module manufacturer’s documentation.
(d) If permission 21.5.lh is implemented in a given S-module, the read function shall occur before the write function.
(e) If permission 21.5.fg is implemented for a given Error/Status register port having port ID ‘0008’, ‘OOO9’, or ‘OOOA’, that S-module shall provide the data from the MTM-Bus register for which the given Errodstatus register port is reserved in the S-module transmitted DATA packet following receipt of the PORT ID packet (17.1.1a; figure 17-1).
(f) If permission 21.5.lg is implemented in a given S-module, the order of registers from which such data are transferred by an uninterrupted sequence of S-module transmitted DATA packets shall be the same as the order specified in the case of a Read Status message (16.1. Id).
NOTE-If, say, the Bus Error register is accessed first, then the Slave Status register cannot be read by the transfer of additional packet pairs in the same message. Likewise, if the Module Status register is accessed first then the Slave Status register and Bus Error register are both inaccessible in the current message.
Permissions
(8) Data from additional S-module status registers may be transferred following transfer of data from the S-module status register (Slave Status, Bus Error, Module Status) for which a given Error/Status register port is reserved.
(h) An Error/Status register port may support the Reamr i t e Data command.
21.5.2 Description
Ports with port IDS ‘0008’ HEX through ‘00OB’ HEX have been reserved for accessing S-module status reg- isters. Ports with port ID’s ‘0008’ HEX, ‘0009’ HEX, and ‘OOOA’ HEX will provide access to the Slave Sta- tus register, Bus Error register, and Module Status register, respectively. An S-module’s manufacturer may provide access to additional status registers via the port having port ID ‘OOOB’ HEX. Contents of S-module
21-5
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
transmitted DATA packets have to be documented. Status registers may be any number of bits in length and their contents have to be transferred consistent with 5.5.1.
As defined in 21.5.la, accessing ports with port IDS ‘0008’ HEX through ‘OOOA’ HEX with the Read Data command will result in a non-destructive read of the S-module status registers (i.e., no bits will be cleared). This is in contrast to the Read Status command (16.1), which will cause error bits to be cleared following the transmission of the contents of an S-module status register.
In the definition of the Read Status command (16.1.1d), it is required of an S-module that all S-module sta- tus registers may be accessed by the M-module in a single command. A sequence for transmission of the contents of the status registers is defined. Permission 21.5.lg and rule 21.5.lf specify that if an S-module is designed to allow transmission of contents of multiple status register through the Error/Status register ports, then beginning with whatever status register is accessed by a given port any number of other status registers may be accessed if they follow the given register in the sequence of transmission determined according to 16.1.ld. Moreover, the sequence of access is the same as it is for the Read Status command.
21.6 MTM-Bus Interface Manufacturer ID port (‘OOOC’ HIEX)
21.6.1 Specifications
Rules
(a) An MTM-Bus Interface Manufact the Read Data command.
NOTE-Attempting to access Reserved command (17.5.1) will access ports having port identifie this port (21.2.la) will cause the
any Data Transfer class t (11.10.1). Attempting to
r class command not supported by
Data Transfer class command that would
r ID port’s supporting the Write Data and not involving this port be provided to allow ted in a given S-module’s MTM-Bus inter-
Reamri te Data modification of a
(c) The port-specific part of the m Interface Manufacturer ID port sh
ala message accessing an MTM-Bus
(d) The format of DATA packets returned by an S-module in the port-specific part of a Read Data message selecting a MTM-Bus Interface Manufacturer ID data shall be as shown in figure 21-2.
(e) If an S-module MTM-Bus interface is implemented within a component containing an IEEE Std 1149.1 vendor-defined ID code, accessible by the IEEE Std 1149.1 IDCODE instruction, the first and second S-module transmitted DATA packets in the port-specific part of a Read Data message accessing an MTM-Bus Interface Manufacturer ID port shall contain the IEEE Std 1149.1 vendor- defined ID code formatted as shown in figure 21-2.
(f) Ifboth
(i) the S-module MTM-Bus interface is implemented within a component containing an E E E Std 1149.1 user-programmable ID code accessible by the E E E Std 1149.1 USERCODE instruction and
21-6
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(ii) permission 21.6.lh is implemented,
the third and fourth S-module transmitted DATA packets in the port-specific part of a Read Data message accessing an MTM-Bus Interface Manufacturer ID port shall contain the IEEE Std 1149.1 user-programmable ID code formatted as shown in figure 21-2.
Recommendations
(g) If permission 21.6.lh is implemented in a given S-module, a mechanism should be provided for writing the user-programmable ID code.
NOTE-Full documentation of such a mechanism is required (22.1.lb).
Permissions
(h) In the case of an S-module satisfying the condition of 21.6.1f(i), a user-programmable ID code may be transferred by the S-module as the third and fourth DATA packets following the Port ID (‘OOOC’ HEX).
optional user programma- p G q y ble identifier (msw)
Figure 21-l-Port-specific portion of slnglecast message format for a Read Data message selecting an MTM-Bus Interface Manufacturer Identification port
Port ‘OOOC’ is reserved for accessing identification data about the MTM-Bus interface manufacturer. This information is useful when multiple MTM-Bus modules from different manufacturers exist within the same system to identify the MTM-Bus implementation pertaining to a particular module address, since module addresses may be programmable. Port ‘O00C’ is only accessible using the Read Data command. When this port is accessed, the addressed S-module returns data that identifies the manufacturer of the MTM-Bus inter- face for that S-module. User-programmable ID information may be transferred following the manufacturer ID. The user-programmable ID code might provide additional information about the capabilities of the addressed S-module’s MTM-Bus interface. The format of the manufacturer ID is shown in figure 21-4 (packets 1 and 2). If the MTM-Bus interface on the addressed S-module is implemented within a component that already contains a vendor-defined ID code (as specified by IEEE Std 1149.1-1990 and accessed by the IEEE Std 1149.1 IDCODE instruction), then the value of that same vendor-defined ID code is returned as the MTM-Bus manufacturer ID (1st and 2nd packets following port ID). If the MTM-Bus interface on the addressed S-module is implemented within a component that contains a user-programmable ID code (as specified by IEEE Std 1149.1-1990 and accessed by the IEEE Std 1149.1 USERCODE instruction), then the
21-7
IEEE Std 1149.5-1995
4 bits
Part no. (Isb’s) Packet 1
IEEE STANDARD FOR MODULE TEST AND
11 bits 1 bit
Manufacturer’s code 1
value of that same user-programmable ID code is returned as the MTM-Bus user-programmable ID (3rd and 4th packets following port ID).
Figure 21-2-Packet formats for S-module Interface Manufacturer Identification port
21.7 Module Manufacturer port (‘OOOD’ HEX)
21.7.1 Specifications
Rules
(a) A Module Manufacturer port shall provide access to the Module Manufacturer ID code having a format as specified for the Block Identifier (Organizationally Unique Identifier [OUI] in LEEE Std 802- 1990).
(b) A Module Manufacturer port shall support the Read Data command.
NOTE-Attempting to access the port having port identifier ‘OOOD’ € E X with any Data Transfer class Reserved command (17.5.1) will cause the ILC bit in the Bus Error register to be set (11.10.1). Attempting to access the port having port identifier ‘OOOD HEX using any other Data Transfer class command not supported by this port (21.2.la) will cause the PTE bit in the Bus Errorregister to be set (11.8.1f).
(c) A Module Manufacturer port shall not support any Data Transfer class command that would permit alteration of the codes that can be read from that port.
N O T G I n particular, this rule forbids a Module Manufacturer port’s supporting the Write Data and Read/ Write Data commands. It is recommended, that a mechanism not involving this port be provided to allow mod- ification of a user-specified Module ID code if such is implemented in a given S-module’s MTh4-Bus interface (21.7. If).
21-8
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(d) The port-specific part of the message format for a Read Data message selecting a Module Manufac- turer port shall be as defined in figure 21-3.
(e) The format of the DATA packets returned by the S-module in the port-specific part of a Read Data message selecting a Module Manufacturer port shall be as shown in figure 21-4.
(f) A 16-bit User-Specified Module ID code should be transferred following the Module Manufacturer ID code (figures 21-3 and 21-4).
(g) An S-module implementing a Module Manufacturer port and implementing recommendation 21.7.lf should provide a mechanism for write access to the optional User-Specified Module ID code.
NOTE-Full documentation of such a mechanism is required (22.1 .lb).
Module Manufacturer ID code (lsw)
-1 Module Manufacturer ID code (msw) 1 ~ 1
-1 I z K E r I Optional User-Specified Module ID Code
Figure 21 -3-Port-specific portion of singlecast message format for a Read Data message selecting a Module Manufacturer Identification port
21.7.2 Description
Port ID “000D is used to provide read access to the Module Manufacturer ID code. This code follows the format of a Block Identifier or Organizationally Unique Identifier (Om). The OUI is a 24-bit code, assigned by the IEEE, that unambiguously identifies manufacmrers implementing IEEE Std 802-1990?
This port provides read access only; a separate mechanism should be provided for writing this data. Other mechanisms might include user-defined commands or write data transfers to a port reserved for module con- figuration.
Although optional, it would be very valuable for an S-module manufacturer to implement a User-Specified Module ID code to further detail the module’s identification by providing a means of electronically record- ing the currently installed software revision or possibly the installation date.
41nterested applicants should contact the IEEE Standards Department, 445 Hoes Lane, Piscataway, NJ 08855-1331, USA.
21-9
IEEE Std 11 49.5-1 995
8 bits
oooooooo Packet 2
IEEE STANDARD FOR MODULE TEST AND
8 bits
IEEE Std 802.3 code (rnsb)
~ ~~ ~
16 bits
iEEE Std 852.3 code (Isw) Packet 1
16 bits
User-specified Module ID code Packet 3
Figure 21 -&Packet formats for Module Manufacturer Identification port
21.8 User Identification ports (‘OOOE HEX - ‘OOOF‘ HEX)
21.8.1 Specifications
Rules
(a) User ID ports shall support
(b) No User ID port shall supp ds that alter the data accessible via that port.
NOTES
1-Attempting to access the port having port identilkr ‘OOOE’ HEX with any Data Transfer class Reserved command (17.5.1) will cause the IUJ bit in the Bus Error register to be set (1 1.10.1). Attempting to access the port having port identifier ‘OOOE’ HEX using any Data Transfer class command not supported by this port (21.2.la) will cause the PTE bit in the Bus Error register to be set (1l.S.lf).
%Packet latency in a Data Transfcr class message selecting a User Identification port has to be documented (21.2. lb).
Recommendations
(c) Packet latency for Data Transfer class messages selecting a User Identification port should be zero.
(d) An S-module implementing an User ID port should provide a mechanism for writing the data acces- sible from that port.
NOTE-Full documentation of such a mechanism is required (22.1.1b).
21.8.2 Description
The User Identification ports, if implemented, may be used to access user-specific identification data. Exam- ples of data that might be accessed include
21-10
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
- Data detailing specific module options; - Data related to module installation; - Data related to the location of the module in a system; - Data related to the system environment.
21.9 Access to status register backup means-Error/Status Shadow register port (‘0080’ HEX)
21.9.1 Specifications
(a) An Errodstatus Shadow register port shall support the Read Data and Write Data commands.
NOTE-Attempting to access the port having port identifier ‘0080’ HEX with any Data Transfer class Reserved com- mand (17.5.1) will cause the ILC bit in the Bus Error register to be set (11.10.1). Attempting to access the port having port identifier ‘0080’ HEX using any user-defined Data Transfer class command not supported by this port (21.2.la) will cause the PTE bit in the Bus Error register to be set (11.8.lf).
(b) Accessing an Error/Status Shadow register port (Port ID ‘0080’ HEX) using the Read Data command shall not change the values in the status register backup means (9.l.ld).
(c) If backup means are provided for multiple S-module status registers in a given S-module that imple- ments an Error/Status Shadow register port,
(i) values in these backup means shall all be accessible Error/Status Shadow register port;
(ii) interpretation of the data returned from that port in such a message shall be detailed in the S- module manufacturer’s documentation;
one Read Data message selecting that
(iii) the data from the status register backup means transmitted in a Read Data message selecting the Errodstatus Shadow register port shall be transmitted in the order in which data from the corresponding status registers are returned in a Read Status message (16.1.1d);
(iv) the first packet of this data shall be transmitted as the first S-module transmitted packet in the port-specific part of a Read Data message selecting the Error/Status register port (17.1.1a; figure 17-1).
NOTE-As a consequence of 21.9.lc, packet latency will be zero packets in a Data Transfer class message selecting an Error/Status Shadow register port.
(d) If permission 21.9.le is implemented in a given S-module, then the read action shall precede the write action.
Permissions
(e) An Error/Status Shadow register port may support the Reamr i t e Data command.
21.9.2 Description
When a status register is read by the Read Status command, its contents are altered-in most cases by error bits being cleared. This is advantageous because new error conditions arising subsequent to the reading of the register (but still within the same message) will be recorded as new errors in the register without ambigu-
21-11
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
ity. However, if for some reason a register has to be ‘‘reread” in such a situation, the original data would be lost-if a shadow-register-type mechanism were not implemented.
The Read Data command (17.2.1) can be used to gain access to data stored in such a shadow-register-type resource if an appropriate POI? is defined such as the recommended Error/Status Shadow register port. Out of continued concern for security (i.e., consistent with the motivation behind 9.1.1d), the contents of these resources should not be altered when they are read.
IEEE Std 1149.1 and the present Standard may be used together within a system to provide hierarchical test capabilities. An appropriate interface between the buses is desirable.There are intrinsic differences between the protocols of this Standard and those of IEEE Std 1149.1 that require attention when designing an inter- face scheme between the two test buses.
One difference is that IEEE Std 1149.1 is a “bit-oriented” protocol in which data bits are transmitted in a constant serial stream until ari operation is completed. IEEE Std 1149.5 is a “packet-oriented” protocol in which data are transmitted serially in multiple packets, each 17 bits in length, separated by bus PAUSE states. Therefore, the traditional IEEE Std 1149.1 data bit stream is divided into multiple packets for trans- port over the MTM-Bus.
A second difference is the clock edge on which data are sourced and captured. IEEE Std 1149.5 sources data onto the bus on the rising edge of MCLK and captures data from the bus on the falling edge of MCLK. IEEE Std 1149.1 sources data on the falling edge of TCK and captures data on the rising edge of TCK. Therefore, interface logic is required to synchronize between the two different clock domains.
This clause provides a set of rules defining common elements in methods-of accessing an IEEE Std 1149.1 boundary-scan path via this Standard. Two specific methods of access are provided: the Full TAP Control (FTC) access method (21.11) and the Function-Based Control (FBC) access method (21.12),
To simplify the wording of the following three su trollers of selected scan paths “selected TAP con
21.10.1 Specifications
9
e adopt the convention of calling the TAP con-
(i) shall provide access to an S-module’s IEEE Std 1149.1 interface(s) using the Full TAP Control access method (21.11.1) or Function-Based Control access method (21.12.1) or both;
(ii) shall support the Reamri te Data command;
(iii) shall not support the Read Data and Write Data commands.
NOTES 1-Attempting to access ports having port identifiers ‘0010’ HEX through ‘001F’ HEX with any Data Transfer class Reserved command (17.5.1) will cause the L C bit in the Bus Error register to be set (1 1.10.1). Attempting to access the ports having port identifiers ‘0010’ HEX through ‘001F‘ HEX using any other Data Transfer class command not supported by the selected port (21.2.la) will cause the PTE bit in the Bus Error register to be set (1 1.8.10.
2-It may be useful to develop an application-specific non-destructive read command that extracts data from a scan chain while simultaneously feeding bits shifted out of TDO back into TDI.
21-12
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(b) At least port ‘0010’ HEX shall provide access to an S-module’s IEEE Std 1149.1 interface(s) using the Full TAP Control access method (21.11.1).
(c) The port-specific part of the format for a Reamrite Data message selecting an IEEE Std 1149.1 Interface port shall be as defined in figure 21-5 and its embedded text.
NOTE-During certain packet transfers at the beginning of the port-specific part of such a Reamri te mes- sage, the S-module may transmit either a NULL packet or a packet containing design specific data. For conve- nience, a new term is defined to described both options with a single symbol: An A.D.S. (Application-Defined Status) packet has to be either a NULL packet or a DATA packet containing status associated with the selected IEEE Std 1149.1 Interface port. See figure 21-5.
(d) The bits of a SELECT packet of a message selecting an IEEE Std 1149.1 Interface port shall be defined by table 21-2.
(e) An addressed S-module shall interpret data of the BIT COUNT packet as defining the number of bits of data per test vector in the remainder of the current message.
NOTE-A value of zero in a BIT COUNT packet effectively terminates test vector transmission (21.10.1j).
(f) To implement the recommended Trigger on Event capability (21.10.10)
(i) Following receipt of a trigger-setting message (21.11.1; 21.12.1), the controller states of the TAP controllers of the selected boundary-scan chain shall be advanced to the point at which the next edge of the signal on TCK would cause entry of the TAP controllers into the Capture-DR (Capture-ZR) controller state; and, at this point, the signal on TCK shall be frozen.
NOTE-This function is expected to be used to scan out the contents of an IEEE Std 1149.1 boundary- scan data register immediately following the occurrence of some application-defined triggering event. If the register in question is the boundary-scan register, the MTM-Bus trigger setting message would have to be immediately preceded by an MTM-Bus message causing the SAMPLWPRELOAD instruction to be scanned into the instruction registers of all devices on the scan chain to be subsequently selected by S.
(ii) The application-defined trigger mechanism shall become active when the S-module’s S- Controller enters its EOM Slave Controller state at the end of a trigger-setting message.
NOTE-The length of the message subsequent to such a SELECT packet is determined by the TAP con- trol method used (21.11; 21.12). For example, the means of moving a TAP controller on a selected scan path to a required controller state requires no input of specific data in the Function-Based Control access method, but requires a packet of TMS data in the Full TAP Control access method.
(iii) The occurrence of the application-defined trigger event shall cause the TCK signal of the selected boundary-scan path(s) to resume activity as rapidly as possible.
N O W T h e resumption of activity on the TCK signal will cause the TAP controllers of the selected boundary-scan path(s) to enter the Capture-DR (Capture-IR) controller state-in accord with the most recent trigger-setting action taken in compliance with 21.10.l.f(i).
21-13
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
transmitted in current messaae. 71 if and only if test data is to be BIT COUNT PACKET -
1 - VECTOR COUNT PACKET Packet pair transmission required if and only if both the MULTI bit was set in the SELECT packet of current message and test data is to be transmitted in current message.
Optional: Message may include 0 or more packet pairs of this type.
-___ - -_ - -__ - - - -___ - -______
_ _ _ _ - _ _ _ _ _ _ _ _ _ _ _ _ _ - - - - - - - - -* DATA PACKET Optional: Message may include 0 71 or more packet pairs of this type. I DATA PACKET - Optional: Message may include 0 1 4- 1-1 or more packet pairs of this type. NULL PACKET
An A.D.S. (Application-Defined Status) packet eilher shall be a NULL packet or shall contain status associated with the selected IEEE Std 1149.1 Interface port. Such status shall be documented by the S-module’s manufacturer.
Figure 21 -5-Port-specific part of redwrite data message selecting an IEEE Std 11 49.1 Interface port
(8) If an S-module jinplciiiciits 1Iic ‘I’riggcr on Event capability, the timing of events described in 21 .lO.lf shall be fully docuincnrztl by thc S-rncdule’s manufacturer.
(h) If an SAmodule iniplcinents the Trigger on Evcn
(i) the \ means by which the user of an S-mo efine a trigger event (21.11.1j through 21.11.h; table 21-3; 21.12.lg) shall be fully documented by the S-module’s manufacturer;
(ii) the set of events that may be trigger events shall be fully documented by the S-module’s man- ufacturer.
(i) An addressed S-module
(9
(ii)
shall interpret the fourth packet of a Reamr i t e Data message selecting an IEEE Std 1149.1 Interface port as a VECTOR COUNT packet (figure 21-5) if and only if the MULTI bit (bit <13> of the SELECT packet of the current message was set;
N O M t h e r w i s e , the fourth packet pair transfer of such a message will be taken to be the first DATA packet pair transfer.
shall interpret data of a VECTOR COUNT packet as defining the number of test vectors to be transmitted in the remainder of the current message.
NOTE-A value of zero in a VECTOR COUNT packet effectively terminates test vector transmission (21.10. lj).
21-14
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
0) When an addressed S-module receives a BIT COUNT packet or a VECTOR COUNT packet con- taining the value zero,
(i) the function receiving data via the selected IEEE Std 1149.1 Interface port shall cause no shifting of the selected scan chain in response to the current message;
(ii) the S-module shall transmit only NULL packets for the remainder of the current message;
(iii) the selected port shall report an error.
NOTE-Reporting an error will have the effect of setting the PTE bit of the Bus Error register (1 1.8.1b).
(k) During a Data Transfer message in which an IEEE Std 1149.1 Interface port is selected,
(i) that port shall report an error (1 1.8.lb) if insufficient data are transferred to make up a complete test vector or set of test vectors-based on the values in the BIT COUNT or VECTOR COUNT packet of the same message;
NO-It is not necessarily an error if more DATA packets are transmitted than are required by the value in the BIT COUNT packet because packet latency may require the M-module to pad the message by transmission of NULL packets.
(ii) that port shall report an error (11.8.1b) if TRIGB or MULTI bits of the SELECT packet are set and the relevant function cannot be executed in the addressed S-module;
NOTE-Inability to execute such a function might be a result of its not being implemented in the given S-module.
(iii) all error conditions defined by 21.10.1k(i), 21.10.lk(ii) shall be fully documented by the S- module's manufacturer.
(1) When multiple test vectors are to be transmitted within a single message, they shall be concatenated into a single bit string prior to transmission as follows: The least significant bit of the n" vector (1 < n < value in VECTOR COUNT packet) shall immediately follow the most significant bit of the n-I" vector.
NOTE-Transmission of long bit strings is addressed in 5.5.lc, 5.7, and figure 5-6.
(m) Packet latency for all IEEE Std 1149.1 Interface ports shall be fully documented by the S-module's manufacturer.
(n) The value 'O0OOOOOO' in the SLCT field of the SELECT packet shall
(i) be interpreted as a command the execution of which will cause all boundary-scan paths of an addressed S-module to be concatenated into a single boundary-scan chain in an order that shall be documented by the S-module's manufacturer;
(ii) be interpreted as the identifier (in the sense of table 21-2) of the single chain of 21.10.1n(i),
Recommendations
(0) A port interfacing to IEEE Std 1149.1 boundary-scan should support the Trigger on Event capability (21.10.ld; 21.10.lf through 21.10.lh).
21-15
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
(p) On an S-module implementing a port interfacing to IEEE Std 1149.1 boundary-scan, one value of the SLCT field of the SELECT packet should be defined that
(i) causes the selected scan path’s(s’) TDI and TDO signals to be disconnected from all boundary- scan paths;
(ii) connects each selected scan path’s TDI signal to that scan path’s TDO signal.
NOTE+Implementation of this recommendation would allow loopback testing of a port interfacing to IEEE Std 1149.1 boundary-scan.
Permissions
(9) After a SELECT packet has been transmitted in which the TLRB bit has been set, the current message may be terminated.
21 -10.2 Description
Figurel7-1 depicts the message format for a Data Transfer class message; and figure 21-5 defines the port- specific part of a ReaWrite Data message selecting an IEEE Std 1149.1 Interface port. For IEEE Std 1149.1 Interface ports, the PORT ID packet of the Read/Write Data message is followed by DATA packets containing additional port-specific addressing/control information and serial scan data.
The SELECT packet provides the capability to select one or more of 256 IEEE Std 1149.1 scan paths to be accessed the SLCT field (bits<8.. I>). rl’l~c SELECT packet also identifies which of two methods is to be used for accessing the selected scan p;ith(s) (bit<l6>). The two methods available are the Full TAP Control (FTC) method (21.11) and the Function Based Control (FBC) method (21.12).
Contents of the TMS/FUNCTION CODE packet is dependent upon which access method is selected (21.11; 21.12) and contains either values to be applied to the TMS signal of the IEEE Std 1149.1 TAP-in the case of the FTC method-or an operation code identifying an operation to be performed-in the case of the FBC method.
The BIT COUNT packet contains a value identifying the number of serial scan bits contained in the data packets of this message.
Two considerations arise when forming the data to be sent to an S-module’s IEEE Std 1149.1 port:
- bit order translation - packetization of the serial scan data
In the IEEE Std 1149.5 protocol, data packets are transmitted most significant bit (msb) first so that lower priority S-modules participating in a Contend for Bus sequence (16.4.1) can detect when to cease participa- tion. In contrast, the IEEE Std 1149.1 protocol requires that data be transmitted least significant bit (lsb) first. One important distinction is that the msb-first transmission on the MTM-Bus applies to each 17-bit packet, not the entire data stream. Bit order conversion between the two buses is solved by loading the MTM-Bus data (msb first) into a holding register with MCLK as a clock, then unloading the register (lsb first) feeding each selected scan path’s TDI input with that scan path’s TCK signal as the clock, and reversing the process for data returned from each selected path’s TDO output signal to the MTM-Bus.
Regarding the packetization of data, the method for subdividing any data bit stream that is greater than 16 bits long (such as an IEEE Std 1149.1 serial sc-m string) into appropriate MTM-Bus packets is specified by 5.5.1~.
21-16
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
Table 21 -2-SELECT packet layout and semantics
Packet bit#
bite 16>
bit<l5>
bite 14>
bitcl3>
bitcl 2. .9>
bitc8.. 1>
NOTE--If 1
Abbrev.
Th4SB
TLRB
TRIGB
MULTI
RESV SLCT
- :15> of a S
Meaning of bit value
'1'-The immediately following DATA packet shall be interpreted by an addressed S-module as con. taining TMS data as defined by implementation of the Full TAP Control access method (21.11).
'U-The immediately following DATApacket shall be interpreted by an addressed S-module as con. taining a functional code defined by implementation of the Function-Based Control access method (21.12). '1'-An addressed S-module shall
(i) if the selected boundary-scan path(s) implement(s) the TRST* signal, cause that TRST* signal to become asserted after the S-module's S-Controller enters its PAUSE Slave Controller state following transmission of the SELECT packet; cause TMS of the selected boundary-scan path(s) to become asserted, NOTE--Because TMS is frozen in the asserted state by requirement ii, no change of controller state. of any TAP controller on the selected scan path@) is possible (once the selected TAP con. trollers are in the Test-Logic-Reset controller state) until TMS becomes active again as a come quence of a subsequent message selecting (one of) (one or more of) the same scan path(s).
(iii) cause the contents of any subsequent packet of the current message to be ignored.
(ii)
'U-An addressed S-module shall (i) cause TRST* of the selected boundary-scan path(s) to be released after the S-
module's S-Controller enters its PAUSE Slave Controller state following trans- mission of the SELECT packet; cause TMS of the selected boundary-scan path(s) to bc ondcr control of thc TMS/ FUNCTION CODE packet (should thcrc be one) in thc current mcssagc.
(ii) .... ._
1'-An IEEE Std 1149.1 Interface port implementing theTrigger on Event capability (21.10.10) and Ieing accessed by the FTC method shall enable (21.10.10 that capability of the selected boundary- ican path(s) unless the MULTI bit is also set. In the latter case, the fact that the TRIGB bit is set shall lave no effect on S-module function-shall neither enable nor disable the Trigger on Event capabil- tY.
U-An IEEE Std 1149.1 Interface port implementing the Trigger on Event capability (21.10.10) and King accessed by the FTC method shall assure that that capability (21.10.10 of the selected bound- uy-scan path@) is disabled.
me state of the TRIGB bit shall have no meaning to an S-module when an IEEE Std 1149.1 Interface )art is being accessed by the FBC method.
1'-An S-module addressed by the FTC method shall interpret this value as meaning that subsequent IATA packets in the current message include data of more than one test vector (the number of vectors ransmitted in the VECTOR COUNTpacket (figure 21-5; 2l.ll.lf)tunless the TRIGB bit is also let. In the latter case, the fact that the MULTI bit is set shall have no effect on S-module function- ,hall be treated as though it were cleared.
@-An addressed S-module addressed by the FTC method shall interpret this value as meaning the emainder of the current message consists of data of a single test vector.
The state of the MULTI bit shall have no meaning to an S-module when an IEEE Std 1149.1 Interface jort is being accessed by the FBC method.
lesemed for use in future versions of this Standard.
in addressed S-module shall interpret this field as an identifier indicating which boundary-scan ,ath(s) on that S-module is (are) to be selected. Moreover, such an S-module shall cause the identified bath(s) to be selected. .Em packet is set, the TAP controllers of the boundary-scan path(s) selected by the value of SLCT, will be in
the Test-Logic-Reset controller stak after five cycles of the TCK signal even if the selected scan path(s) do(es) not implement the TRST* signal.
21-17
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
Another important consideration when interfacing this Standard to E E E Std 1149.1 is the relationship of the clocks. If the MTM-Bus MCLK signal is asynchronous with the E E E Std 1149.1 TCK signal, then a mech- anism has to be available for synchronizing the data flow between the two clock domains. A simple solution is to register 16-bit data in each of the clock domains and move data between the registers during periods when the relevant S-module’s S-Controller is in its PAUSE Slave Controller state and the IEEE Std 1149.1 TAP controllers of the selected scan paith(s) are in the Pause-DR or Pause-IR controller state. Appropriate use of these states also will allow time for parity checking of each incoming MTM-Bus packet. If the IEEE Std 1149.1 TCK signal is operating at a slower frequency than is the MCLK signal, the S-module interface has to control MTM-Bus data transfer using the MPR signal. If the TCK signal is operating at a faster fre- quency than is the MCLK signal, then either the E E E Std 1149.1 TAP controllers’ Pause-DR (Pause-ZR) state may be used or the signal on TCK may be stopped after each DATA packet’s worth of input is shifted into the selected scan path’s(s’) TDI input. To ensure safe operation, if the received DATA packets contain bad parity, the data should not be transmitted onto the IEEE Std 1149.1 bus. Error handling for a Parity Error will give rise to an interrupt, and it may be an important consideration to program the interrupt capability of the S-module to make such errors evident to the M-module as rapidly as possible.
The SELECT packet defined in table 21-2 contains three additional bits (bits<15..13>) for supporting optional features of IEEE Std 1149.1 and increasing data transfer throughput when accessing a boundary- scan chain.
The TLRB bit (bit<l5>) of the SELECT packet supports control of the IEEE Std 1149.1 optional TRST* signal. The function of this bit applies regardless of the method of access (FTC or FBC). If the TLRB bit is set, the module-level TRST* signal of the selected scan path(s) will be asserted. If the TLRB bit is set and the TRST* signal is not implemented for the selected scan path(s), the selected TAP controllers will still be in the Test-Logic-Reset controller state within 5 cycles of the signal on the selected scan path‘s(s’) module- level TCK input. The function supported by the TLRB bit is necessary in order to allow a coordinated reset of an S-module’s IEEE Std 1149.1 scan jpath(s).
The TRIGB bit (bit<l4>) of the SELECT packet supports a trigger arming capability to be used to synchro- nize IEEE Std 1149.1 capture operation to bccurrence of a specified event. The TRIGB bit is optional and only applies to the FTC access method (21.11). The same capability is provided through the TRIGGER IR and TRIGGER DR operation in the FBC method (table 21-3; 21.12.lg). If the TRIGB bit is set, data stored in the TMSFUNCTION CODE packet are applied to the gnal and the signal on TCK is frozen just prior to the edge that would cause the sellected TAP controllers to enter the Capture-DR controller state. The TCK signal is halted until a specified module event occurs. Upon detection of the event, the remaining data from the TMSFUNCTION CODE packet are applied to the TMS signal, causing transition of the selected TAP controllers to the Pause-DR state. The Pre-Scan TMS Data field (bits<16..9>) of the TMS/FUNCTION CODE packet represent the “Pre-Trigger” TMS data. The Post-Scan TMS Data field (bits<8..1>) of that packet represent the “Post-Trigger” T M S data. The ‘Re- Trigger” TMS data will vary depending upon the initial controller state, but should always be such that the relevant TAP controllers
- will be in the Select-DR-Scan controller state after b i t < l b is transmitted on TMS; - would go into the Capture-DR c:ontroller state as a consequence of transmission of bit<9> on the
selected scan path’s(s’) TMS inplut were it not for the freezing of the selected scan path’s(s’) TCK signal.
The “Post-Trigger” TMS data will always be a fixed value (‘Ol(lOOOO0’) to cause the selected TAP controller to make transition to the Pause-DR state,, without any data shifting.
Capture of data in a selected boundary-scan register after the occurrence of a trigger event may be instanta- neous or non-instantaneous and may be predefined by the manufacturer of an S-module or programmable through additional M-module transmitted DATA packets following the TMSIFUNCTION CODE packet. The event trigger function is of significant importance when attempting to debug module operations by cap-
21-18
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
turing data on the selected scan path(s) in coordination with a specific event (internal module condition, external signal, etc.).
The MULTI bit (bit<l3>) of the SELECT packet supports multi-vector transfers to an IEEE Std 1149.1 Interface port. This optional capability allows multiple IEEE Std 1149.1 data register scans to be performed during a single MTM-Bus message, increasing the throughput of the IEEE Std 1149.1 interface. If the MULTI bit is cleared, a separate MTM-Bus message is required for every IEEE Std 1149.1 scan operation (i.e., shifting of one serial test vector). If the MULTI bit is set, the DATA packet following the BIT COUNT packet is interpreted as a VECTOR COUNT packet. The VECTOR COUNT packet indicates the number of IEEE Std 1149.1 serial test vectors to be transmitted in the current message. The VECTOR COUNT packet is followed by DATApackets containing the serial test vectors. Note that all IEEE Std 1149.1 serial test vec- tors have to be of the same length.
21.11 IEEE Std 1149.1 Interface ports-requirements for the Full TAP Control (FTC) access method
21 .11.1 Specifications
Rules
(a) In a case of application of the Full TAP Control access method, the TMSAWNCTION CODE packet shall have the format defined in figure 21-6.
PRE-SCAN TMS DATA ! POST-SCAN TMS DATA
bit numbers I 16 1011911 8 In
Figure 21-&Format of TMWFUNCTION CODE packet in the case of the Full TAP Control access method
(b) A message using the Full TAP Control access method shall be of one of the following types:
(i) a single vector transfer message (21.11.1~ through 21.11.lf; 21.11.1i);
(ii) multi-vector transfer message (21.11.lg through 21.11.1i);
(iii) a trigger setting message (21.10.lf through 21.10.lh; 21.10.10; table 21-2; 21.11.lj through 21.11. In);
(iv) a trigger disarming message (table 21.2; 21.11.10; 21.11.1~);
(v) a reset message (a message in which the TLRB bit of the SELECT packet is set-previously specified by 21.10.ld and table 21-2).
(c) A single vector transfer FTC message shall be an instance of the message format defined in figure 21-5 and shall satisfy all the following:
(i) The message shall include a BIT COUNT packet;
(ii) The message shall not include a VECTOR COUNT packet and, consequently, the MULTI bit (bit c13>) shall not be set in the SELECT packet of the message;
21-19
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
(iii) The message shall include precisely the number of RI-module (S-module) transmitted non- NULL DATApackets necessary to transmit B bits-where B is the value transmitted in the BIT COUNT packet of the message;
(iv) The DATA packets specified by 21.11.lc(iii)&all contain a bit string the length of which is equal to B;
(v) The message shall include precisely the number of M-module (S-module) transmitted NULL packets equivalent to the manufacturer specified packet latency of such a message.
(d) The bit string specified in 21.11.1c(iv) shall be interpreted by the function receiving data via the selected port as a bit string to be shifted into the IEEE Std 1149.1 boundary-scan chain selected by means of the SELECT packet of the message.
NOTELTO convey to an S-module that a single vector transfer FTC message is underway, the M-module has to transmit a SELECT packet with the following bit settings required The TMSB bit is set; the TLRB bit is cleared; the TRIGB bit is cleared; and the MULTI bit is cleared. In other words, bits46.. 13> of the SELECT packet have to be ‘1000.’
(e) For each single vector transfer ETC message selecting E E E Std 1149.1 Interface port, P, the fol- lowing shall hold:
(i) The message shall include a given assumed starting c
ansition of the selected TAP controllers from the Shij3-DR or Shi$-IR controller state.
(ii) Thedatair.l:\T>iti.: ?!.ll.?i~~i’ishaii hctransmit Scan TMS Data field of the TMS/
1 be interpreted by the function receiving it via the port P to be 8 \i:!ii,,\ I O be o the TMS input of the selected scan path(s) (ordered by descending value of the bit position in the TMS/FUNCTION CODE packet) in eight consecutive cycles of the signal e TCK input of the selected scan path(s).
(iv) Subsequently, while the selected TAP controllers remain in the controller state determined in conformance with 21.11.le(i) through 21.11.le(iii), the function receiving data via the port P shall cause the bit string defined in 21.1 l.lc(iv) to be scanned into the TDI input of the selected scan path(s).
NOTE-It is a consequence of 21.11.1e(i) through 21.11.1e(iv) that the last value applied to the TMS input of the selected scan path@) due to the action of 2l.ll.le(iii) will be held constant throughout the scanning pro- cess of 2l.ll.le(iv).
(v) The message shall include data that shall cause transition of the selected IEEE Std 1149.1 TAP controllers from the controller state determined in conformance with 21.11,le(i) through 2 1,l l . le(iii) to a controller state in which the TAP controllers may remain indefinitely if the TMS signal is held constant and the signal on TCK is active.
(vi) The data satisfying 21.11.1e(v) shall be transmitted in the Post-Scan TMS Data field of the TMS/FUNCTION CODE packet (figure 21-6) of the message.
(vii) The 8-bit string satisfying 21.11.1e(v) and 21.11.1e(vi) shall be interpreted by the function receiving it via the port P to be 8 values to be applied to the TMS input of the selected scan path(s) (ordered by descending value of the bit position in the TMS/FUNCTION CODE packet) in eight consecutive cycles of the signal on the TCK input of the selected scan path(s) following the scan action specified in 21.11.le(iv).
2 1-20
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(viii)Following the action specified in 21.11.1e(vii), the value of bit<l> of the Post-Scan TMS Data field of the TMS/FUNCTION CODE packet (figure 21-6) shall be maintained on the TMS signal of the selected scan path(s) until altered by a subsequent Reamr i t e command selecting P.
(f) A multi-vector transfer FTC message shall be an instance of the message format defined in figure 21-5 and shall satisfy all the following:
(i) The message shall include a BIT COUNT packet.
(ii) The message shall include a VECTOR COUNT packet and, consequently, shall have the MULTI bit (bit <13>) set in the SELECT packet of the message.
(iii) The message shall include precisely the number of M-module (S-module) transmitted non- NULL DATA packets necessary to transmit the number of bits specified by value transmitted in the BIT COUNT packet of the message multiplied by the value transmitted in the VECTOR COUNT packet.
(iv) The DATA packets specified by 21.11.1c(iii) shall contain a bit string the length of which is equal to the value, B, transmitted in the BIT COUNT packet of the message multiplied by the value, V, transmitted in the
(v) The message shall include p -module (S-module). transmitted NULL packets equivalent to the manufacturer specified packet latency of such a message.
(g) The bit string specified in 21.11.1f(iv) shall be interpreted by the function receiving data via the selected port as a bit string to be shifted into the IEEE Std 1149.1 boundary-scan chain selected by means of the SELECT packet of the message; moreover, that bit string shall be interpreted as con- sisting of V substrings composed of B bits each.
NOTE--To convey to an S-module that a message of this type is underway, the M-module has to transmit a SELECT packet with the following bit settings required: The TMSB bit is set; the TLRB bit is cleared; the TRIGB bit is cleared; and the MULTI bit is set. In other words, bits<16..13> of the SELECTpacket have to be ‘1001.’
(h) For each multi-vector transfer FTC message selecting IEEE Std 1149.1 Interface port, M, the fol- lowing shall hold:
(i) The message shall include data that shall cause transition of the selected IEEE Std 1149.1 TAP controllers from a given assumed starting controller state to either the Shijt-DR or Shijt-ZR con- troller state.
(ii) The data satisfying 21.11.1 h(i) shall be transmitted in the Pre-Scan TMS Data field of the TMS/ FUNCTION CODE packet (figure 21-6) of the message.
(iii) The 8-bit string satisfying 21.11,1h(i) and 21.11.1h(ii) shall be interpreted by the function receiving it via the port M to be 8 values to be applied to the TMS input of the selected scan path@) (ordered by descending value of the bit position in the TMS/FUNCTION CODE packet) in eight consecutive cycles of the signal on the TCK input of the selected scan path(s).
(iv) Subsequently, the function receiving data via the port M shall cause the bit string defined in 21.11.1f(iv) to be scanned into the TDI input of the selected scan path(s) and shall manipulate the value of the TMS input of the selected scan path(s) so that after every bit string of length B (21.11.1g) is scanned into the TDI input, the selected TAP controllers will be made to make
21-21
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
transitions taking the shortest path from the Shzft-DR (Shift-ZR) controller state reached per 21.1 1.1 h(i) through 21.11.1h(iii) through the corresponding Update-DR (Update-ZR) controller state and back to the Shift-DR (Shift-ZR) controller state.
NOTES
1-In the case of a multi-vector transfer message, operation is very much the same as with the single vector transfer message except that the function receiving data via the IEEE Std 1149.1 Interface port has to take an action equivalent to applying the bit string ‘1 1100’ to the TMS input between the scanning of any two serial test vectors.
2-It is a consequence of 21.11.1h(i) through 21.11.1h(iv) that, whiie the scanning process of 21.11.1h(iv) is underway, the value being applied on the TMS input of the selected TAP is the last of the 8 values applied as specified in 21.11.1h(iii).
(v) The message shall include data that shall cause transition of the selected TAP controllers from the controller state determined in conformance with 21.11.1h(i) through 21.11.1h(iv) to a con- troller state in which the TAP controllers may remain indefinitely if the TMS signal is held constant and the signal on TCK is active.
(vi) The data satisfying 21.11.1h(v) shall be transmitted in the Post-Scan TMS Data field of the TMSFUNCTION CODE packet (figure 21-6) of the message.
(vii) The 8-bit string satisfying 21.11.1h(v) and 2l.ll.lh(vi) shall be interpreted by the function receiving it via the port M to be 8 values to be applied to the TMS input of the selected scan path(s) (ordered by descending value of the bit position in the TMS/FUNCTION CODE packet) in eight consccutive cycles of the signal on the TCK input of the selected scan path(s) following the scan action specified in Zl.ll.lh(iv).
(viii) Following the action specified in 21.11.1 h(vii), the value of bit<l> of the Post-Scan TMS Data field of the TMSEUNCTION CODE packet (figure 21-6J shall be maintained on the TMS signal of the selected scan path(s) until altered by a subsequent Reamr i t e command selecting M .
(i) The non-NULL and non-A.D.S. DATA packets transmitted by an S-module in a single (multi-) vector transfer message shall contain the bit string (concatenation of bit strings) equal to the data shifted out of the selected scan chain when the M-module transmitted bit string(s) were shifted into that scan chain per 21.11.1c(iv), 21.11. Id, 21 .l l.le(iv), 21.11.1 f(iv), 21.11.1 g, 21.11.1 h(iv).
(i) A trigger setting FTC message (21.10.lf through 21.10.lh; 21.10.10) shall include only a SELECT packet and a TMSFUNCTION CODE packet and those M-module transmitted DATA packets (if any) necessary to program the trigger function.
NOTE-To convey to an S-module that a message of this type is underway, the M-module has to transmit a SELECT packet with the following bit settings required: The TMSB bit is set; the TLRB bit is cleared; the TRIGB bit is set; and the MULTI bit is cleared. In other words, bits<16..13> of the SELECT packet have to be ‘1010.’
(k) An S-module function implementing the Trigger on Event capability and receiving a trigger setting FTC message via an IEEE Std 1149.1 Interface port shall interpret the 8 bits of the Pre-Scan TMS Data as data to be applied to the TMS signal of the selected scan path(s) during 8 consecutive cycles of the signal on TCK of the selected scan path(s) with the purpose of causing the selected TAP con- trollers
(i) to make transition from an assumed starting controller state to the Cupture-DR (-ZR) controller state (21.10.1f(i));
21-22
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 11 49.5-1 995
(ii) to do this in such a way that the first 7 bits applied shall result in the selected TAP controllers being in the Select-DR(-IR)-Scan controller state.
NOTE-According to 21.10.1f(i), the edge of the TCK signal that would cause the transition into the Cupture- DR (-ZR) controller state will not be transmitted to the selected scan path@) until the defined trigger event occurs-the TCK signal is frozen until the defined trigger event occurs.
(1) A trigger-setting FTC message shall include in the Post-Scan TMS Data field of its TMS/ FUNCTION CODE packet the bit string ‘01000000.’
NOTE-The post scan bit string required for TMS will leave the selected TAP controller in its Puuse-DR (-ZR) controller state. It is important that this be done; otherwise, a set of TAP controller state transitions including one into the Capture-DR (-ZR) controller state will occur before it is possible to scan out data captured in response to the trigger event.
(m) The %bit string of the preceding rule (21.11.11) shall be interpreted by the function receiving it via the selected port to be 8 values to be applied to the TMS input of the selected scan path(s) (ordered by descending value of the bit position in the TMS/FUNCTION CODE packet) in eight consecutive cycles of the signal on the TCK input of the selected scan path(s) following the detection of a trigger event as defined in 21.10.lf.
(n) Following the action specified in 2 1.11.1 m, the value of bitcl> of the Post-Scan TMS Data field of the TMS/FUNCTION CODE packet shall be maintained on the TMS signal of the selected scan chain until altered by a subsequent Reamr i t e command selecting that scan chain.
(0) A trigger-disarming FTC message shall include a SELECT packet transfer and no other subsequent packet transfer (figure 21-5).
NOTE-To convey to an S-modulc that a message of this typc is undcrway, the M-module has to transmit a SELECT packet with the follo\ving bit scttings required The TMSB bit is set; the TLRB bit is cleared; the TRIGB bit is cleared; and thc hlUl.Tl hit is cleared. In other words, bitsc16..13> of the SELECT packet have to be ‘1000.’
(p) An S-module function implementing the Trigger on Event capability and receiving a trigger dis- arming FTC message via an IEEE Std 1149.1 Interface port
(i) shall begin the disarming process when that S-module’s S-Controller enters its EOM Slave Controller state;
(ii) shall cause any trigger that is currently set to fire;
(iii) shall clear any bit in that S-module’s status registers that would have been set if the trigger had been fired due to the occurrence of a trigger event.
NOTE-The methodology required for disarming the trigger avoids a race between the disarming function and a trigger event that happens to occur nearly simultaneously with disarming.
21 .I 1.2 Description
The Full TAP Control access method allows M-module control of state transitions of a selected IEEE Std 1149.1 scan path prior to and following the shifting of data into the scan path’s TDI input. This is achieved by providing for 8 bits of pre-scan and 8-bits of post-scan control transmitted in the TMS/FUNCTION CODE packet (figure 21-6). These two bit strings are of sufficient length to get from an original stable state in a TAP controller to the Shift-DR (Shift-ZR) controller state before the (first) test vector is scanned into T D I and cause a TAP controller to make transition to a stable state after the shifting is completed. (There are four stable states: Pause-IR, Pause-DR, Run-Tesfldle, and Test-Logic-Reset. Holding a TAP controller in any
2 1 -23
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
other state requires stopping the signal on TCK-halting M e r IEEE Std 1149.1 boundary-scan opera- tions.)
The 8 bits of the bit string from the Pre-Scan TMS Data field of the TMS/FUNCTION CODE packet are applied to the TMS signal of the selected scan path(s) on eight consecutive cycles of TCK in conformance with IEEE Std 1149.1 protocol. The bits are applied in sequence from bit<l6> to bit<9>. Bit<9> of this packet is applied constantly to the TMS signal of the selected scan path(s) for the number of cycles on the TCK signal determined by the value in the BIT COUNT packet. This provides the means of clocking the transmitted test vector into the TDI input. The Pre-Scan TMS Data bit string is padded (if necessary) in the high order bits; only the transmission of bit<9> can cause a TAP controller to make transition into the desired shifting controller state.
Following the shifting of data into TDI, bits-&. 1> of the TMSlFLTNCTION CODE packet are applied to the TMS signal as were bits<16..9>. The effect is the reverse-the selected TAP controllers make a series of transitions beginning with the shifting state and terminating in a stable state. Bit<l> of the Post-Scan TMS Data field is applied constantly to the TMS input until changed by the next MTM-Bus message targeting the selected scan path(s).
If the value in the BIT COUNT packet is zero, all 16 bits of TMS data in the TMS/FUNCTION CODE packet are applied to TMS in 16 consecutive cycles of the signal on TCK. This operation can be used to cause a TAP controller to make transition between any two of its stable states. In the case of the Post-Scan TMS Data, padding may be added in the lower order bits-maintaining the selected TAP controllers in the desired, terminal stable state.
Example: Assume that the selected the end of the last Reamr i t e Data leave the TAP controllers in the Paus sequence. For simplicity, we assume
Test-Logic-Reset controller state at . Also, assume that it is desirable to f the planned test vector scanning
- The TMSNNCTION CODE packet SO’HEX-defining the TMS data necessary to cre- ate the desired state transitions.
- The BIT COUNT packet is set to ‘2A’HEX, indicating the number of bits in the serial test vectors to be applied to TDI and captured from TDO during the message. Bits<l6..9> in the TMS/FUN(-JTION CODE packet (1111 0100) cause the selected TAP controllers to make transition to its Shif-DR
- While the selected TAP controlle troller state, 42 (’2A”EX) bits of serial test vector data (transmitted into the selected module-level TDI input; and 42 bits of response data and transmitted to the M-module in 3 DATA packets.
- Bits<8..1> of the TMSFUNCTION CODE packet (loo0 oo00) cause the selected TAP controllers to make transition from its Shift-DR controller state to its Pause-DR controller state, where it remains until the next MTM-Bus message selecting this scan path (note padding in low order bits).
- g in high order bits).
In the case of a multi-vector transfer message, operation is very much the same except that the function receiving data via the IEEE Std 1149.1 Interface port has to take an action equivalent to applying the bit string ‘11100’ to the TMS input between the scanning of each serial test vector (except the last one) and the next. This sequence of values applied to TMS causes the selected TAP controllers to make transition from the Shift-DR controller state through the Exit1 -DR, Update-DR, Select-DR-Scan, and Capture-DR controller states and back to the original shifting controller state so that the next serial vector may be scanned into TDI.
The Full Tap Control access method is very simple and direct, but there are several drawbacks. Due to the simplicity of this interface and the complete control over state transitions of the selected TAP controllers, there are no provisions to check for TMS sequences that would cause unexpected action to occur. This can lead to dangerous scenarios if the TMS values are not programmed properly or the current state of the
2 1-24
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
selected TAP controllers for a given path is not remembered. This Standard does not specify the method for determining the current controller state of the selected TAP controllers of a given scan path; it is expected that the MTM-Bus M-module software will track this information or that the M-module will be transmitting automatically generated data the generation of which guarantees no problems. Having a fixed practice of starting and stopping stable states will greatly simplify automatic or manual generation of the TMS Data bit strings.
The FTC method has to be supported by the MTM-Bus data transfer port having port ID ‘001o”EX and is selected by setting the TMSB bit (bit<l6>) of the SELECT packet. The FTC method may also be supported by MTM-Bus data transfer ports having port IDS in the range ‘OOll’HEX to ‘001F‘HEX.
21.12 IEEE Std 1149.1 Interface ports-requirements for the Function-Based Control (FBC) access method
21 -12.1 Specifications
Rules
(a) The Function-Based Control access method shall provide access to the scan path(s) selected by a message through a set of operations s
(b) The set of operations in the left-in required of a port supporting the FBC mcdiod.
NOTE-Opcl-iilioris iiro associated will1 r7 liniilcd I (“Initial controllcr state”) illid thrcc (“Teriiiin;il co about a spccilic application of an opcration in tcri controller .sw/c>. Tlio scls ol‘ iiiilial mil tcrinina When no action for a givcn opcration is specified initial stalc, thc opcriition is noi pcrfor
(c) A function receiving/traiisinitting data via an IEE d 1149.1 Interface port on a given S-module
(i) shall keep a record of the state of TAP controllers on the scan path(s) of the S-module;
(ii) shall not perform operations transmitted to that function when the TAP controllers are not pres- ently in an initial controller state assumed by the operation (i.e., a controller state appearing in column two [“Initial controller state”] of table 21-3 in a row having the transmitted operation name in column one [“Operation (operation code)”]);
(iii) if the condition proscribing performance of an operation in 21.12.1c(ii) holds, shall cause the selected port to report an error.
NOTE-If such a capability were not implemented, it would be possible for errors in operation sequence transmitted to a selected scan path to cause selected TAPS to enter an unintended terminal state. If the initial controller state were Run-TesUZdle instead of Pause-DR, execution of the <MASS PDR, Pause-DR, Pause- DR> operation would result in the selected TAP controllers ending in the Run-TestLdle controller state instead of the Pause-DR controller state. Worse, if the initial controller state were Run-TestLdle instead of Pause-DR, execution of the M A S S RTI, Pause-DR, Run-Test/Zdle> operation would end with the TAP controllers caus- ing shifting of whatever might be on the selected scan path’s TDI input into selected instruction registers on every cycle of the TCK signal until another message changes the TAP controllers’ states.
(d) The bits from a bit string in column four (“Minimal sequence on TMS needed for transition”) of table 21-3 shall be applied in descending value of bit position in that bit string according to the require-
2 1-25
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
ments of the fifth column (“Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions”).
(e) Operation codes shall be no more than 16 bits long and shall be transmitted as the contents of the TMSPUNCTION CODE packet of a message accessing an IEEE Std 1149.1 Interface port using the FBC method.
(f) The MASS TLR, MASS RTI, MASS PDR, and MASS PIR operations shall be transmitted in mes- sages selecting an EEE Std 1149.1 Interface port by the FBC method and having a message format that shall include only those packet pair transmissions depicted in figure 21-5 that are not optional packet pair transmissions.
(g) The TRIGGER DR, TRIGGER IR, and DISARM operations shall be transmitted in messages selecting an IEEE Std 1149.1 Interface port by the FBC method and having a message format that is an instance of the message format defined in figure 21-5 that
(i) shall not contain a BIT COUNT packet;
(ii) shall not contain a VECTOR COUNT packet;
(iii) shall contain only those optional f ) N ‘ A packct Ir.aiisfcr-s necessary to program the Trigger on Event capability.
NOTE-The TRIGB bit of the SELECT packet has no effect in a message accessing an IEEE Std 1149.1 Interface port by the FBC method (table 21 -2).
(h) The SHIFT operation shall be transmitted in mcssages selecting an IEEE Std 1149.1 Interface port by the FBC method and haviiig 21 illeshiige format that is an instance of that specified in figure 21-5 satisfying the following conditions:
(i) The message shall iiicludc ii 131-1’ COUNT packet with contents that shall be interpreted as they are in single vector transmission messages using the FTC access method (21.11.1c(i); 21.11. Ic(iii); 21.11.1c(iv));
(ii) The message shall not include a VECTOR COUNT packet;
(iii) The message shall provide for transmission of serial test data that shall be formatted and inter- preted precisely as in the case of single vector transmission using the FTC access method (21.1 l.c(iii) through 21.11.1c(v); 21.11.1d).
(i) The UPDATEBHIFT operations shall be transmitted in messages selecting an IEEE Std 1149.1 Interface port by the FBC method and having a message format that is an instance of that specified in figure 21-5 satisfying the following conditions:
(i) The message shall include a BIT COUNT packet with contents that shall be interpreted as they are in multi-vector transmission messages using the FTC access method (21.11.1f(i): 21.11.1 f(iii); 2 1.11.1 f(iv));
(ii)The message shall include a VECTOR COUNT packet with contents that shall be interpreted as they are in multi-vector transmission messages using the FTC me@od (21.11.1f(ii) through 21.11.1 f(iv));
2 1-26
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
(iii) The message shall provide for transmission of serial test data that shall be formatted and inter- preted precisely as in the case of multi-vector transmission using the FTC access method (21.10.11; 21.11 .f(i) through 21.1 l.lf(v); 21.11. lg).
NOTE-The MULTI bit of the SELECT packet has no meaning in a message accessing an IEEE Std 1149.1 Interface port by the FBC method.
When the function receiving data via an IEEE Std 1149.1 Interface port is accessed by the FBC method and receives an operation code that is not defined, that function shall cause the port to report an error.
The APPLY TEST operation shall be transmitted in messages selecting an IEEE Std 1149.1 Interface port by the FBC method and having a message format that is an instance of that specified in figure 2 1-5 satisfying the following conditions:
(i) The message shall not include a BIT COUNT packet;
(ii) The message shall not include a VECTOR COUNT packet;
(iii) The message shall include at least one DATA packet transmitted by the M-module, and this packet shall be transmitted immediately following the TMS/FUNCTION CODE packet and shall be interpreted as containing the number of cycles of the TCK signal of the selected TAP that have to elapse with selected TAP controllers in their Run-Tesu‘ldle controller states in order for execution of a previously loaded boundary scan instruction to be completed.
NOTE-In table 21-3, the APPLY TEST operation is dcfined by means of a controller state sequence to bring the selected TAP controllers to their Rw-Tesr/ldle controller states, a period of time in which the selected TAP controllers remain in that controller state, and a subsequent controller state sequence returning the selected TAP controllers to a stable controller state-either Pause-IR or Pause-DR. The integer value in the DATA packet defined in 21.12.lk(iii) specifies the time period in which the selected TAP controllers remain in their Run-TestLIdle controller states.
Permissions
(1) Operation codes not required by an operation defined in table 21-3 may be used for user-defined operations.
NOTE--Full documentation of s operations is required (22. I . 1 a).
21.12.2 Description
The FBC method of accessing an IEEE Std 1149.1 Interface port allows a “higher level” of control than that of the FTC method. The FBC method is optional for all JEEE Std 1149.1 Interface ports and can be specified for a given message selecting such a port by having the TMSB bit (bitcl6>) of the SELECT packet of that message cleared. This method uses a set of primitive, predefined operations to cause state transitions of the selected TAP controllers. The operation to be performed is specified through operation codes transmitted in the TMS/FUNCTION CODE packet (figure 21-5). Unimplemented function codes cause no change in the state of the TAP controller(s), but cause a data transfer error to occur as documented by the port definition. The FBC method focuses on cycling TAP controllers between stable states. A stable state is defined as one of the controller states in which a TAP controller can remain if the value of TCK input continues to cycle while the value applied to the TMS input of the TAP is constant.
One set of operations defined for the FBC method controls movement between stable states of a TAP con- troller, with no associated data transfer. These operations all have names beginning with “MASS” (Move to Adjacent Stable State). For example, a MASS PDR operation causes the selected TAP controllers to move
2 1-27
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TEST AND
from a given initial controller state to the Pause-DR controller state. A predefined TMS sequence for such an operation is built into an appropriate S-module application.
A SHIFT operation causes the selected TAP controllers to make transition from one of the Pause-DR (-ZR) controller state to the corresponding Shift-DR (-ZR) controller state and to begin shifting data. A SHIFT oper- ation code requires the BIT COUNT packet (indicating the number of bits to be shifted) and an appropriate number of data packets containing the scan data to be presented on the TDI signal during shifting. These data are formatted exactly as described under the Full TAP Control access method.
If a given IEEE Std 1149.1 Interface port implements the Trigger on Event capability, the operations with names beginning with “TRIGGER” cause arming of the trigger and the appropriate manipulation of both TMS and TCK to place the necessary function in the condition where it is prepared to cause the capture of data if the trigger event should occur. The Trigger on Event capability is discussed in 21.10.2. The data cap- tured when the trigger is armed and the trigger event occurs can be accessed by using the SHIFT operation. The DISARM operation disarms the Trigger on Event capability and causes selected TAP controllers to make the transition to a stable state [Puuse-DR (-IR)]. The state of the TRIGB bit of the SELECT packet of a given message is ignored if that message accesses an E E E Std 1149.1 Interface port by the FJ3C method (table 21-2).
Example: To cause Built-In Self-Test (BIST) to be executed in an IC conformant to IEEE Std 1149.1, the following set of operation transmitted in an uninterrupted sequence of messages selecting the desired scan chain will suffice:
scan path@) include the instruction ition for loading into the instruction
In addition to the operations described here, numerous user-defined operations can be designed because of the excess of unused operation codes.
The FBC access method is very useful for simplifying Operation within a debug or integration environment, as well as in a system testing environment. Control over an IEEE Std 1149.1 test bus is provided by means of a set of core capabilities. The price for this higher-level operation is additional circuitry required for the increased intelligence on board an S-module. Unlike the FTC method, the FBC method requires that the S- module interface maintain current information regarding the controller state of all TAP controllers on an S - module.
21-28
IEEE Std 11 49.5-1 995 MAINTENANCE BUS (MTM-BUS) PROTOCOL
Table 21-3-Specification of operations for FBC access method of IEEE Std 1149.1 Interface port
Terminal controller
State
MiniUMl sequence
on TMS needed for transition
Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions
Fire the trigger Clear any bit in any status register
that would cause an interrupt to be signaled indicating that the trigger event occurred.
Trigger on Event capability armed TCK stopped selected TAP controlle ready to enter Capture (-IR) controller state
21-29
IEEE Std 11 49.5-1 995 IEEE STANDARD FOR MODULE TESTAND
Table 21 -3-Specification of operations for FBC access method of IEEE Std 1149.1 Interface port (Confinued)
Operation (operation code)
Initial controller state
Terminal controller
state
Minimal sequence
on TMS needed for transition
Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions
I I I I For the following operations, two TMS sequences are required. These operations all have the characteristic that they invoke a con- troller state transition sequence followed by an action that occurs during a period while the selected TAP controllers state does not change followed by a second controller state transition sequence. In the fourth column, below, the first TMS sequence shall be the one on the left of the hyphen; and the second TMS sequence shall be the one on the right of the hyphen.
APPLY TEST (‘100’)
. -
Pause-DR
SHIFT (‘101’)
Pause-DR
Pause-IR
Pause-DR
Pause - IR
Pame-DR
Pause-IK
110 - 1010
110 - 11010
10- 10
10- 10
First controller state sequence (CSS): Exit2-DR, Update-DR, Run- TesUIdle
Execute instructions previously shifted into IEEE Std 1149.1 instruc- tion registers on selected scan path(s).
Second CSS: Select-DR-Scan, Cap- ture-DR, Exitl -DR, Pause-DR
0 First CSS: Exit2-IR, Update-IR, Run-TestLdle
Execute instructions prcviously shifted into IEEE Std 1149.1 instruc- tion registers on selected scan path@). * Second CSS: Select-DR-Scan, Se- lect-IR-Scan, Capture-IR, Exitl -IR, Pause-IR
9 First CSS: Exit2-Dli, Shut-IlK * Shift serial test data into TDI in- put(s) of selected scan path(s)
Second CSS: Exitl-DK, Pause-DR
First CSS: Exit2-IR, Shtf-IK Shift instruction into TDI input of
selected scan path(s) Second CSS: Exitl-IR, Pause-IR
21-30
MAINTENANCE BUS (MTM-BUS) PROTOCOL IEEE
Std 1149.5-1995
Table 21-3-Specification of operations for FBC access method of IEEE Std 1149.1 Interface port (Continued)
I Operation
(operation code) Initial
controller state
TRIGGER DR
rhese operations shall be the means 3f activating the l’rigger on Event :apability when ac- :essing an IEEE Std 1149.1 Interface iort with the FBC nethod.
(‘11W)
hese operations ;hall have no effect f the selected port ioes not implement he Trigger on hent capability 2 1.10.1 f through !l. 10-1 h; !l.lO.lo; table 21-
Pause-DR
!).
Pause-IR
Terminal controller
state
Pause-DR
Minimal sequence
on TMS needed for transition
10- 10
1110 - 10
1110- 10
Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions
First CSS: Select-DR-Scan Arm trigger and wait for trigger
event If trigger event occurs, final control-
ler state transition of first CSS takes place: Capture-DR
second CSS: Exitl-DR, Pause-DR First CSS: Exit2-DR, Update-DR,
Select-DR-Scan Arm trigger and wait for trigger
event If trigger event occurs, final control-
ler state transition of first CSS takes place: Capture-DR
Second CSS: Exitl-DR, Pause-DR
First CSS: Exit2-IR, Update-IR, Se- lect-DR-Scan Arm trigger and wait for trigger
event If trigger event occurs, final control-
ler state transition of first CSS takes place: Capture-DR
Second CSS: Exitl-DR, Pause-DR
IEEE Std 1149.5-1995 IEEE STANDARD FOR MODULE TEST AND
TRIGGER IR
shall be means of activating the Trig- ger on Event capa-
accessing an IEEE Std 1149.1 Interface port with the FBC
shall have no effect
does not implement
21.10.10: table 21-
Table 21-3-Specification of operations for FBC access method of IEEE Std 1149.1 Interface port (Continued)
Initial controller state
Test-Logic-Reset
Run-TesYldle
Pause-DR
Pause-IR
Terminal controller
state
Pause-IR
Minimal sequence
on TMS needed for transition
0110 - 10
110 - 10
11110- 10
Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions
First CSS: Run-TeMdle, Select-DR Scan, Select- IR-Scan
Arm trigger and wait for trigger event
If trigger event occurs, final control ler state transition of first CSS takes place: Capture-IR 9 Second CSS: Exitl-IR, Pause-IR
First CSS: Select-DR-Scan, Select- IR-Scan 0 Arm trigger and wait for trigger event
If trigger event occurs, final control ler state transition of first CSS takes place: Capture-IR
Second CSS: ExitI-IR, Pause-IR
First CSS: Exit2-DR, Update-DR, Select-DR-Scan, Select-IR-Scan * Arm trigger and wait for trigger event
If trigger event occurs, final control ler state transition of first CSS takes place: Capture-SR
Second CSS: Exitl-SR, Pause-IR
First CSS: Exit2-IR, Update-IR, Se- lect-DR-Scan, Select-IR-Scan 0 Arm trigger and wait for trigger event
If trigger event occurs, final control ler state lransition of first CSS Lakes place: Capluiu-IR
Sccond CSS: Exitl-IR, Pause-IR
21-32
MAINTENANCE BUS (MTM-BUS) PROTOCOL
Rcscrvcd codcs ( ' I 01 0' -' 1 1 1 1 1 ')
Table 21 -3-Specification of operations for FBC access method of IEEE Std 1149.1 Interface port (Continued)
undefincd
Operation Initial (operation code) controller state
( ' 1001 ' ) NOTE-UP- DAWSHIFT is the only operation that supports a multiple vector transfer using FBC.
I
I
Terminal controller
state
Pause-DR
Pause-IR
undefined
MinilIlal sequence
on TMS needed for transition
11100 - 10
111100 - 10
undefined
IEEE Std 1149.5-1895
Required IEEE Std 1149.1 TAP controller state sequence and
' required coordinated actions
First CSS: Exit2-DR, Update-DR, Select-DR-Scan, Capture-DR, Shifi- DR
Shift serial test data into TDI input of selected scan path(s)
Second CSS: Exit2-DR, Pause-DR If last serial vector transmil ted not
yet scanned into selected scanpath(s), repeat 9 First CSS: Exit2-IR, Update-IR, Se- lect-DR-Scan, Select-IR-Scan, Cap- ture-IR, Shift-IR
Shift instruction into TDI input of selected scan path(s) 8 Second CSS: Exit2-IR, Pame-IR *If last instruction transmitted not yet scanned into selccted scan path(s), rc- peat
-
None of these operation code:$ shall be assigned a function by users of this Standard.
21-33
IEBE Std 11 49.5-1 995
22. MTM-Bus general documentation requirements
Documentation requirements for specific features are found in the text describing that feature. General requirements for documentation are located in this clause.
22.1 Documentation requirements
22.1 .l Specifications
(a) Any Module or IC that claims conformance to this Standard shall document any implemented Rec- ommendations or Permissions.
(b) When implementation of a Recommendation or Permission requires the development of a user-puo- grammable capability, all details of such programming shall be fully documented.
(c) Any S-module or IC that claims conformance to this Standard shall document which instruction codes may cause hazardous operating Conditions.
(d) For any S-module that claims conformance to this Standard, the response to all implemented com- mands (except as concerned with hazardous instructions mentioned in 22.1.1~) shall be fully docu- mented.
(e) For any S-module that claims conformance to this Standard, the data transfer ports implemented shall be fully docurnentcd and defined as noted in 21.2.1.
(f) The following information, required by the Module or IC purchaser for test development and other activities, shall be supplied by the Module or IC manufacturer:
(i) Physical protocol: Optional MPR signal use, signal outputs under loss of power condition, output level representing logic 1, m i n i m m MCLK high time supported ( t l ) , minimum MC1.K low time supported (to), and mini&m-sum of MCLK low and high times (tl + to).
(ii) Bus Error register: User-defined Error and Status bit definition, including the bits and asso- ciated transitions that cause the BSE bit in the Slave Status register to be set; timing of settilng of BMR bit by any commands for which such detail is required.
(iii) Module Status register: Error and Status bit definition, including the bits and associated transi- tions that cause the EVO bit in the Slave Status register to be set.
(iv) Additional Status registetfs): Error and Status bit definitions, including the bits and associated transitions that cause the EVO bit in the Slave Status register to be set, Method(s) of Access via Read Status and/or Data Transfer commands.
(v) Read Status command: Maximum packets of status that should be requested.
(vi) Abort command Maximum time MTM-Bus will be off-line, time required to execute, stability of applications circuit state after execution of the Abort command (both between messages and during execution of subsequent commands), method(s) (if any) of evaluating application circuit status after execution of the Abort command.
22- 1
IEEE Std 11 49.5-1 995
(vii) Initialize Application command: Maximum time MTM-Bus will be off-line, time required to execute, method(s) (if any) of evaluating application circuit status after execution of the Ini- tialize Application command.
(viii)Reset Module With SBITcommand: Maximum time MTM-Bus will be off-line, Time required to execute.
(ix) Reset Module Without SBlT c o r n & T i e required to execute.
(x) Module Initiated Built-In Test (IBIT) conwnad: Time required to execute, results of B I T accessible through additional status registers.
(xi) Disable Module U0 command: Disable values for ALL outputs, time required from command receipt to outputs disabled.
(xii) Enable Module U0 command: Time required from command receipt to outputs enabled.
(xiii)Force Module Outputs command: Time required for input data to be available on output pins, What module output pins are controllable through this command, What is the required format for the data associated with this command.
(xiv)Sample Module commands: Which sample commands are implemented, what signals are not sampled, what is the required format for the data associated with these commands.
(xv) Command Execution: For d l impiemented commands, when, in relation to the end of transfer of the HEADER packet of last packet of a message, a commalid wnveyed by that message will begin and end execution. How the presence of errors affect egecution of each implemented command.
