IEEE 1149-5-1995 - Archived

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 Board
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 maintainable 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 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. 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 10017-2394, USA Copyright 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 participating 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, market, 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 ve years for revision or reafrmation. When a document is more than ve years old and has not been reafrmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reect 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 IEEE Standards are welcome from any interested party, regardless of membership afliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specic applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason IEEE and the members of its technical committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA
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, signicant interest in developing an industrial standard based on this test and maintenance bus were registered. The level of interest was sufcient 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 nal draft from the previous Department of Defense efforts. This draft was signicantly modied to remove all project specic artifacts from previous standardization efforts and generalized to allow applicability to all types of systems. An additional major effort was required to clarify ambiguities so that 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 substantial 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 species a backplane for embedded systems. Work is continuing on the application of the MTM-Bus in VME64 standard extensions and applications. At the time of approval of this standard, the P1149.5 MTM-Bus Working Group had the following membership: Patrick F. McHugh, Chair Rodham E. Tulloss, Technical Editor
Dave Heiligenstein Christopher M. Henwood Jeffrey W. Lundy Michel Parot Gregory D. Young Gerry Kendzior Russell A. Manseld
iii
The following persons were on the balloting committee:

Jacob A. Abraham Dharma P. 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 Hearn 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 Karrfalt Mehdi Katoozi William Keiner Charles Kime Steven K. Ladd David Landis Bjorn B. Larsen Luis Larzabal Robert Ledbetter Ben Lee Marc Levitt Jeffrey W. Lundy R. A. Manseld Ken Mason Colin Maunder Thomas J. McGrath Earl Meiers Alex Meloni Yinghua Min Math Muris H. Troy Nagle, Jr. Prawat Nagvajara James Nagy Roy H. Nesson Yoshinori Ninohira Arnold Nordsieck Paul Ocampo 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. Turino 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. Al Kiener, Chair Donald C. Loughry, Vice Chair Andrew G. Salem, Secretary
Richard J. Holleman Jim Isaak Ben C. Johnson Sonny Kasturi Lorraine C. Kevra Ivor N. Knight Joseph L. Koepnger* D. N. Jim Logothetis L. Bruce McClung Marco W. Migliaro Mary Lou Padgett John W. Pope Arthur K. Reilly Gary S. Robinson Ingo Rusch Chee Kiow Tan Leonard L. Tripp
Gilles A. Baril Clyde R. Camp Joseph A. Cannatelli Stephen L. Diamond Harold E. Epstein Donald C. Fleckenstein Jay Forster* Donald N. Heirman *Member Emeritus
Also included are the following nonvoting IEEE Standards Board liaisons:
Satish K. Aggarwal Richard B. Engelman Robert E. Hebner Chester C. Taylor
Paula M. Kelty IEEE Standards Project Editor
Contents
CLAUSE PAGE
1.
Overview.......................................................................................................................................... 1-1 1.1 1.2 1.3 1.4 1.5 1.6 Scope and objectives .............................................................................................................. 1-1 Interconnection of modules with MTM-Bus.......................................................................... 1-2 Relationship to other test buses .............................................................................................. 1-3 Overview of MTM-Bus operation/protocol ........................................................................... 1-3 MTM-Bus protocol layers ...................................................................................................... 1-5 Extensions to this Standard .................................................................................................... 1-6
2.
Conventions, definitions, and references .......................................................................................... 2-1 2.1 2.2 2.3 2.4 Document outline ................................................................................................................... 2-1 Conventions............................................................................................................................ 2-1 Definitions .............................................................................................................................. 2-2 References ............................................................................................................................ 2-10
3.
MTM-Bus architecture...................................................................................................................... 3-1 3.1 3.2 3.3 MTM-Bus signals and interconnection of MTM-Bus modules via these signals .................. 3-1 General architecture and MTM-Bus mastership .................................................................... 3-2 S-Module addressing requirements ........................................................................................ 3-3
4.
MTM-Bus Physical Layer requirements........................................................................................... 4-1 4.1 4.2 4.3 4.4 Physical Layer requirements independent of module type..................................................... 4-1 M-module Physical Layer requirements ................................................................................ 4-2 S-Module Physical Layer requirements ................................................................................. 4-3 MTM-Bus timing requirements.............................................................................................. 4-4
5.
MTM-Bus Link Layer: Packet requirements.................................................................................... 5-1 5.1 5.2 5.3 5.4 5.5 5.6 5.7 Requirements applicable to all packets .................................................................................. 5-1 HEADER packet requirements............................................................................................... 5-1 ACKNOWLEDGE packet requirements................................................................................ 5-2 PACKET COUNT packet requirements ................................................................................ 5-3 DATA packet requirements.................................................................................................... 5-4 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 MPR signal (data transfer control) requirements ............................................... 6-10 M-module response to collision errors on MMD and MCTL signals .................................. 6-11 M-module interrupt response requirements.......................................................................... 6-11
vii
CLAUSE
PAGE
7.
MTM-Bus Link Layer: S-module requirementsMTM-Bus Slave Link Layer Controller............ 7-1 7.1 7.2 MTM-Bus Slave Link Layer Controller requirements ........................................................... 7-1 S-module interface logic requirements................................................................................... 7-8
8.
MTM-Bus Link Layer: S-module requirementsgeneral communications.................................... 8-1 8.1 S-module send and receive parity requirements ....................................................................... 8-1 8.2 S-module MSD signal general requirements ............................................................................ 8-1 8.3 S-module MTM-Bus Pause Request (MPR) signal implementation (data transfer control) requirements.............................................................................................................................. 8-2
9.
MTM-Bus Link Layer: S-module requirementsstatus registers ................................................... 9-1 9.1 9.2 9.3 9.4 9.5 S-module status registersgeneral requirements .................................................................. 9-1 Slave Status register ............................................................................................................... 9-2 Bus Error register ................................................................................................................... 9-7 Module Status register.......................................................................................................... 9-15 Additional status registers .................................................................................................... 9-16
10.
MTM-Bus Link Layer: S-module interrupt generation .................................................................. 10-1 10.1 Interrupt generation other than immediate response to a State Sequence Error................... 10-1
11.
S-module error response requirements ........................................................................................... 11-1 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10 11.11 11.12 S-module error responsegeneral requirements ................................................................. 11-1 S-module self-test failure response requirements................................................................. 11-3 Broadcast and multicast errors ............................................................................................. 11-4 S-module Data Overrun Error and response requirements................................................... 11-5 S-module Parity Error response requirements...................................................................... 11-5 S-module State Sequence Error response requirements ....................................................... 11-6 MSD signal collision response requirements ....................................................................... 11-8 S-module Data Transfer Port Error response requirements ................................................. 11-9 S-module Command Sequence Error response requirements ............................................ 11-10 S-module Illegal Command Error response requirements ................................................. 11-11 S-module Packet Count Error response requirements........................................................ 11-12 S-module Command Resource Unavailable Error response requirements ........................ 11-13
12.
MTM-Bus Message Layer: General requirements ......................................................................... 12-1 12.1 MTM-Bus Message Layer general requirements ................................................................. 12-1
13.
MTM-Bus Message Layer: M-module requirements ..................................................................... 13-1 13.1 M-module PACKET COUNT packet transmission requirements ....................................... 13-1 13.2 Post-error recovery at packet and message levels ................................................................ 13-1
viii
CLAUSE
PAGE
14.
MTM-Bus Message Layer: S-module requirements....................................................................... 14-1 14.1 S-module general HEADER packet decode and general command response requirements ......................................................................................................................... 14-1 14.2 S-module packet-counting requirements .............................................................................. 14-2 14.3 Summary of S-module message sequence requirements...................................................... 14-3
15.
MTM-Bus Message Layer: Commandsgeneral requirements ................................................... 15-1 15.1 MTM-Bus commandsgeneral requirements on command codes and command classes ................................................................................................................................... 15-1 15.2 Commands execution of which may be terminated upon receipt of another command ...... 15-4
16.
MTM-Bus Message Layer: Core class commands (00000000011111; 1111111) ....................... 16-1 16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 16.9 16.10 16.11 16.12 16.13 16.14 16.15 16.16 16.17 The Read Status command (0000000) ................................................................................. 16-1 Abort command (0000001) .................................................................................................. 16-4 Reset Slave Status command (0000010) .............................................................................. 16-5 Contend for Bus command (0000011) ................................................................................. 16-6 Multicast Select n commands (n = 0, 1, 2, 3) (00001000000111) ..................................... 16-9 Enable Idle Interrupts command (0001000)....................................................................... 16-11 Enable Pause Interrupts command (0001001).................................................................... 16-11 Disable Idle Interrupts command (0001010)...................................................................... 16-12 Disable Pause Interrupts command (0001011)................................................................... 16-13 Enable Module Control (EMC) command (0001100)........................................................ 16-13 Data Echo Test command (0001101) ................................................................................. 16-15 Verify BMR command (0001110) ..................................................................................... 16-16 The Initialize Application command (0001111) ................................................................ 16-18 Disable Module Control command (0010000)................................................................... 16-19 Start command (0010001) .................................................................................................. 16-20 Reserved command (00100100011111)........................................................................... 16-21 Illegal command (1111111) ............................................................................................... 16-21
17.
MTM-Bus Message Layer: Data Transfer class commands (01000000100111) ......................... 17-1 17.1 17.2 17.3 17.4 17.5 General format requirements for Data Transfer class commands ........................................ 17-1 Read Data command (0100000)........................................................................................... 17-2 Write Data command (0100001) .......................................................................................... 17-4 Read/Write Data command (0100010)................................................................................. 17-5 Reserved commands (01000110100111) ........................................................................... 17-7
18.
MTM-Bus Message Layer: Module Initialization and Self-Test (MIST) class commands (0100000010011).......................................................................................................................... 18-1 18.1 18.2 18.3 18.4 18.5 General requirements for MIST commands ......................................................................... 18-2 Reset Module With Start-up Built-in Test (SBIT)) command (0101000) ........................... 18-2 Reset Module Without SBIT command (0101001).............................................................. 18-4 Module Initiated Built-in Test (Module IBIT) command (0101010)................................... 18-5 Reserved commands (01010110101111) ........................................................................... 18-7
ix
CLAUSE
PAGE
19.
MTM-Bus Message Layer: Module I/O Control and Test (MICT) class commands (01100000110111)....................................................................................................................... 19-1 19.1 19.2 19.3 19.4 19.5 19.6 19.7 19.8 19.9 19.10 MICT class commandsgeneral requirements ................................................................... 19-2 Disable Module I/O command (0110000)............................................................................ 19-4 Enable Module I/O command (0110001)............................................................................. 19-6 Force Module Outputs command (0110010) ....................................................................... 19-7 Sample Module Inputs commands (01100110110101)general requirements ................ 19-9 Sample Module No Change command (0110011) ............................................................. 19-11 Sample Module Dont Care command (0110100) ............................................................. 19-11 Sample Module With Force command (0110101) ............................................................. 19-12 Release Module I/O command (0110110) ......................................................................... 19-13 Reserved commands (01101111001111) ......................................................................... 19-14
20.
MTM-Bus Message Layer: Standard Extension class commands (10100001011111) and User-Defined class commands (11000001111110) ...................................................................... 20-1 20.1 Standard Extension class commands (10100001011111) .................................................. 20-1 20.2 User-Defined class commands (11000001111110)............................................................ 20-1
21.
Data transfer ports........................................................................................................................... 21-1 21.1 21.2 21.3 21.4 21.5 21.6 21.7 21.8 21.9 Data transfer portsgeneral requirements........................................................................... 21-1 Port definition and documentation requirements ................................................................. 21-3 Module/Fault log port(s) (0000 HEX 0003 HEX) ....................................................... 21-3 Test Data Storage ports (0004 HEX 0007 HEX) ......................................................... 21-4 Error/Status register ports (0008 HEX 000B HEX)..................................................... 21-5 MTM-Bus Interface Manufacturer ID port (000C HEX) .................................................. 21-6 Module Manufacturer port (000D HEX) ........................................................................... 21-8 User Identification ports (000E HEX 000F HEX) ..................................................... 21-10 Access to status register backup meansError/Status Shadow register port (0080 HEX)...................................................................................................................... 21-11 21.10 Ports interfacing to IEEE Std 1149.1 boundary-scan (0010' HEX 001F' HEX) .......... 21-12 21.11 IEEE Std 1149.1 Interface portsrequirements for the Full TAP Control (FTC) access method..................................................................................................................... 21-19 21.12 IEEE Std 1149.1 Interface portsrequirements for the Function-Based Control (FBC) access method..................................................................................................................... 21-25
22.
MTM-Bus general documentation requirements ............................................................................ 22-1 22.1 Documentation requirements................................................................................................ 22-1
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 eld-replaceable, unit immediately above the device-level in a systems assembly hierarchye.g., assembled printed wiring boards, assembled multichip modules, etc.) The bus protocol dened in this document standardizes a method for communication of test and maintenance 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 individual 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, initiation of self-test, reconguration of subsystem resources, and other diagnostic functions. Software/hardware development. Access to a module or subsystem state by use of low-level observability/controllability techniques (e.g., scan, boundary scan, etc.). Use of these techniques may allow for reduced hardware/software development costs and decreased time to market. To support these applications, the MTM-Bus is designed as a serial backplane bus with a multidrop topology. As the multidrop bus signals are common between all modules, a board may be removed from the backplane 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 dened so that the MTMBus Master may communicate with one, some, or all of the Slaves at one time. The physical backplane characteristics will dene 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 implementation while still deriving the benets of improved testability and maintainability. For this reason, a serial bus with a limited number of signals was selected. A master/slave protocol is used to keep the protocol simple; thereby reducing interface circuitry and software requirements. The bus is synchronous to simplify the backplane 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 signicant 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 specied in this document, a general timing approach is dened 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 timing budget. To aid interoperation of modules from multiple vendors, a dual-edge clocking approach is utilized. 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 tolerance features. Optional features have been dened that may be included for a particular test architecture. To support the requirements described previously, the protocol identies commands to provide for the following functions: Initialization of module/subsystem Accessing lower-level test buses Testing of module interconnections Interrupt control and handling Accessing module identication Accessing module fault logs Forcing modules off- and on-line Accessing module built-in test features Private and public user extensions
1.2 The interconnection of modules with MTM-Bus

As designs have become more complex and difcult 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 functional 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 bootstrapping to complete module testing from a testable kernel is feasible. When components are assembled on boards, boards into subsystems, and subsystems into systems, a hierarchy of test buses is needed to retain access to the design-for-test features in the nal product. Such a hierarchy of test buses is depicted in gure 1-1. The MTM-Bus has been developed to meet the requirements for a backplane bus in such a bus hierarchy. As shown in gure 1-1, the MTM-Bus provides subsystem test control (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 benets of both distributed and centralized approaches are outlined in the following lists. Benets of distributed approach: 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.
1-2
MAINTENANCE BUS (MTM-BUS) PROTOCOL
IEEE Std 1149.5-1995
MTM-Bus
Other Modules
Component Level Test Bus
Other Components Comp. Test Interface Boundary Scan
System Bus
Subsystem Test Control
Test-bus Interface
Application Logic
Component Board or Module Rack or Subsystem NOTEHierarchical serial test buses may be used to access module- and component-level design-for-test features.
Figure 1-1Hierarchy of test and maintenance buses
Simplication of software. Since the distributed test circuitry and software allows for higher-level test functions/commands, less software is required in the Subsystem Test Control module (gure 1-1) for each specic type of module. Distributed software can reduce the software development time and simplify module upgrades. Containment of bus trafc. If self-test routines and test patterns are contained on the individual modules, bus trafc is restricted to high-level commands and compressed test results. Interchangeability. If test patterns or procedures specic to a modules low-level design are contained within the module, then modules with identical function, but different design, can be made fully interchangeable. Benets of a centralized approach: Cost reduction. By centralizing the test sequencing function to a single processor on a Subsystem Test Control module (gure 1-1), test sequencing capability 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-specic test information, a common test interface can be used on a large number of modules without need for module-specic 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 gure 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 fth signal, as detailed in gure 1-3. An MTM-Bus Master module can communicate with up to 250 individually 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 congurations of the bus. The multidrop architecture and addressing capabilities of this Standard allow the MTM-Bus Master to address and communicate with one, some (multicast), or all (broadcast) of the MTM-Bus Slave modules on the bus.
1-3
IEEE Std 1149.5-1995
MTM-Bus
Bus Transceiver Test-bus Interface Other Board-level Test Buses IEEE Std 1149.1 Test Bus
NOTETranslation 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 specic applications.
Figure 1-2Translation between the MTM-Bus and on-module test buses
MTM-Bus Master
MTM-Bus Slave
MTM-Bus Slave
Master Data (MMD) Slave Data (MSD) Clock Source Pause Request (MPR) Control (MCTL) Clock (MCLK)
NOTEThese 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 recommended 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
1-4
IEEE Std 1149.5-1995
packet includes a request for an ACKNOWLEDGE packet, the MTM-Bus Master sends the PACKET COUNT packet while the addressed MTM-Bus Slave is returning the ACKNOWLEDGE packet. This PACKET COUNT packet identies 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 depending upon the command. If multiple MTM-Bus Slaves are addressed (i.e., via broadcast or multicast addressing), 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 constant logic 0the value of the Slave Data line (gure 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
HEADER
PACKET COUNT
ACKNOWLEDGE
1st M-module DATA
1st S-module DATA
2nd M-module DATA
2nd S-module DATA
nth M-module DATA
nth S-module DATA
NOTEMTM-Bus messages consist of a single HEADER packet, an optional ACKNOWLEDGE/PACKET COUNT packet pair, and a variable number of DATA packet pairs.
Figure 1-4Sample MTM-Bus 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 ow 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 identied 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 gure 1-5.
1-5
IEEE Std 1149.5-1995
The Physical Layer requirements specify the physical interconnections that comprise the bus. This includes the specication of the minimum requirements regarding physical interconnections, signal characteristics, and timing characteristics. The minimum requirements for the Physical Layer are specied in clause 4. The Physical Layer characteristics that are specic to system technology are not dened in this Standard. The architecture of the MTM-Bus and its addressing scheme are specied 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 specied in clauses 5 through 11 of this Standard.
Applications
Master Message Layer Master Link Layer Physical Layer
Slave Message Layer Slave Link Layer
Applications
NOTEThe MTM-Bus protocol includes Physical Layer, Link Layer, and Message Layer protocols.
Figure 1-5Protocol layers Message layer requirements specify the syntax for messages and identies the functions that have to or can be supported by the MTM-Bus Master or MTM-Bus Slaves. Requirements for the Message Layer are specied in clauses 12 through 20. Port requirements describe a set of recommended or permitted data sources/destinations (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 dened herein for the MTM-Bus may be extended to meet the needs of specic applicationsas detailed by the recommendations and permissions. These extensions may address such areas as fault tolerance, electrical characteristics, and others that allow the MTM-Bus to be adapted to user applications. 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 Division members (see SAE AS4765).1 This system will contain dual MTM-Buses (2 sets of 5-wire MTM1Information
on references can be found in 2.4.
1-6
IEEE Std 1149.5-1995
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 trafc to verify that the current MTM-Bus Master module is functioning correctly.
1-7
IEEE Std 1149.5-1995
1-8
IEEE Std 1149.5-1995
2. Conventions, denitions, and references

2.1 Document outline
Bus protocols such as that dened by this Standard are more easily understood if their specications 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 specications 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 Specications Subclauses entitled Specications contain the rules, recommendations, and permissions that dene this Standard: Rules specify the mandatory aspects of this Standard. Specications that are rules contain the word shall. Recommendations indicate preferred practice for designs that seek to conform to this Standard. Specications that are recommendations contain the word should. Permissions show how optional features may be introduced into a design that seeks to conform to this Standard. These features will extend the application of the protocol dened by the Standard. Specications that are permissions contain the word may. 2.1.2 Descriptions Material not contained in subclauses entitled Specications is descriptive material that illustrates the need for the features being specied, an example of their application, or other relevant information. This material includes bus packet or message sequences or schematics that illustrate a possible implementation of the specications in this Standard. The descriptive material also discusses design decisions made during the development of this Standard.
NOTEThe descriptive material contained in this Standard is for illustrative purposes only and does not dene a preferred implementation.
2.2 Conventions
The following conventions are used in this Standard: a) The rules, recommendations, and permissions in each Specications subclause are contained in a single alphabetically indexed list. References to each rule, recommendation, or permission are written in the following form: 15.1.1c(ii) Subclause number Index (if any) b) State and packet names dened in this Standard are written entirely in capital letters in the text of this Standard.
2-1
IEEE Std 1149.5-1995
c) d) e) f) g)
h) i) j)
k)
A positive logic convention is used for all gures in 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 identied by number with the least signicant bit numbered 0. The identier 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 (< and >). The expression <m..n> is used as an abbreviated identier 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 signicant bits, respectively. The phrases signal driver(s), signal output(s), and signal input(s), when implicitly or explicitly referring to MTM-Bus signals, shall be taken to refer to one or more MTM-Bus signals exclusive 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 elds within registers and packets, the most signicant bit (msb) of each depicted element is assumed to be left-most within the rectangle dening the data entity. Any reference to a gure in this document is intended to reference all drawings and text in that gure.
2.3 Denitions
The following terms are used within this Standard. Clause, subclause, table, or gure numbers are given in parentheses to indicate specic places in the text where terms are discussed in detail. 2.3.1 ACKNOWLEDGE packet: The rst packet returned by an individually addressed S-module that conveys 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 active-low), this term identies the logic level to which a signal shall be set to cause a dened action to 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) implements the ability to detect when it cannot determine its address unambiguously and (2) detects that it cannot determine its address unambiguously (3.3). 2.3.4 application logic: That portion of a module that excludes the MTM-Bus interface logic (gure 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 interconnecting those modules. The intermodule wiring of the MTM-Bus is expected to be on this motherboard. 2.3.8 BMR: Acronym for broadcast/multicast 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
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 conditions associated with message transmission. The register may be interrogated by the M-module. Some bits in the register are reserved for application-specic 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 ip-op or latch, may perform an operation. 2.3.19 collision: The condition occurring when two MTM-Bus modules are simultaneously MTM-Bus drivers 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 bit in the Bus Error register of all S-modules. An Smodule sets this bit to indicate that resources required to complete execution of a command were not available 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-module sets this bit to indicate that the module has received a command that requires a previous enabling command 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 (11.9) will occur. 2.3.26 CRU: Acronym for Command Resource Unavailable. (See 2.3.21.)
2-3
IEEE Std 1149.5-1995
2.3.27 CSE bit: Acronym for Command Sequence Error. (See 2.3.22.) 2.3.28 Data Overrun Error (DOR) 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 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. (See 2.3.27.) 2.3.31 ECL: Acronym for emitter coupled logic. 2.3.32 EMC: Acronym for Enable Module 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 (11.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. (See 2.3.34.) 2.3.36 falling edge: The transition from a logic one to logic zero. 2.3.37 fsm: Acronym for nite state machine. 2.3.38 HEADER packet: A packet originating in the MTM-Bus Master that is the rst packet of an MTMBus message. The HEADER packet includes an address and a command eld. The address identies which S-module(s) are to interpret and act upon the command contained within the command eld (5.2). 2.3.39 IBIT: Acronym for initiated built-in test. 2.3.40 Idle Interrupts Enabled (IIE) 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 S-idle states (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. 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
IEEE Std 1149.5-1995
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 specied 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 signicant bit (lsb): The bit having the smallest effect on the value of a binary numeral; usually the right-most bit in gures. 2.3.53 least signicant 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 signicant bit. (See 2.3.52.) 2.3.57 lsw: Acronym for least signicant 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 (gure 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 elds 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 denes the class C.
2-5
IEEE Std 1149.5-1995
2.3.64 messages, species of: A group of messages having in the Command elds 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 denes the message species. 2.3.65 MICT: Acronym for Module I/O 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. 2.3.68 module: An addressable unit or interconnected set of units attached to the MTM-Bus and fully supporting the MTM-Bus protocols. The boundary of an MTM-Bus module may correspond to the physical partitioning of the system, but is not required to do so. For the purposes of this document, a module is comprised of an MTM-Bus interface and module application logic, as shown in gure 2-1.
MTM-Bus
MTM-Bus Interface Logic
Module Application Logic
An MTM-Bus Module NOTEAn MTM-Bus module consists of MTM-Bus interface logic and module application logic.
Figure 2-1MTM-Bus module 2.3.69 module address: An eight-bit value uniquely identifying an MTM-Bus module. 2.3.70 Module Fail Status (MFS) bit: A bit in the Slave Status register of every S-module that is set by the S-module when the modules built-in test has failed or is currently executing (9.2). 2.3.71 Module Status register: A status register that is recommended to be implemented in the MTM-Bus interface circuitry of every S-module. The bits in this register are dened by the manufacturer of the MTMBus interface circuitry of an S-module. The bits of such a register may serve to record error-condition detection or the modules application-related status (9.4). 2.3.72 most signicant bit (msb): The bit having the greatest effect on the value of a binary numeral; usually the left-most bit in gures. 2.3.73 most signicant 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 signicant bit. 2.3.75 MSB0; 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 signicant word. (See 2.3.76.)
2-6
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 specied in this Standard. 2.3.79 MTM-Bus interface logic: The portion of a module that is designed for the purpose of MTM-Buscompliant 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 dened 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 predened subset of the S-modules currently connected to the bus. Also, a message transmitted in this mode. 2.3.84 multicast select bit 0; multicast select bit 1 (MSB0; MSB1): 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 possible 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 dened 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 (MSB0; MSB1). 2.3.86 multidrop: Said of the conguration 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 eld entirely lled 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 send/receive message, the number of packet transfers by which the rst non-NULL DATA packet returned by the addressed S-module lags the rst non-null DATA packet transmitted by the M-module.
2-7
IEEE Std 1149.5-1995
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 Smodule-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 execute the 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 11)e.g., by ceasing to execute the current command, by returning NULL packets when data is expected, by driving a constant value on the MSD signal 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 Smodule 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 data transferred by a Data Transfer class command into and/or out of an S-module (clause 21). A port may be an on-module memory, on-module interface, a peripheral attached to a module, or some other mechanism to/from which data is passed. Within this Standard, a port is dened by a module address, a port ID meaningful to the MTM-Bus interface logic of that module, and the semantics and structure of packets by which data can be conveyed to and/or from that port. This latter often entails some description of the application to/from which data are passed. A port is selected/accessed/addressed via a Data Transfer class command. 2.3.100 PORT ID packet: The rst DATA packet transferred in a Data Transfer class message. This packet contains the identier (Port Identier) by which means a port is selected for the remainder of the message. 2.3.101 Port Transfer Error: A port-specic error indicating some failure with relation to transmission of command or data to/from a currently selected port. 2.3.102 Port Transfer Error (PTE) bit: A bit in the Bus Error register of all S-modules. An S-module sets this bit to indicate that the port selected by the command in the current message has reported a Data Transfer Port Error. Such errors will be found dened in the port documentation of specic S-modules. The acronym 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 modules releasing a signal line produces 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 MTMBus 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-modules Status registers defined by 9.2.1b, 9.3.1b, 9.4.1b, and 9.5.1bthe state of these registers produced by execution of the Reset Slave Status command (16.3.1).
2-8
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-modules action that is a direct consequence 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 gure 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 ACKNOWLEDGE/PACKET 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-module 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) required of S-modules that controls S-module Link Layer behavior during message transmission to the module. 2.3.121 Slave Data Fault (SDF) 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 interface 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 occurred, 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 Smodule sets this bit to indicate that the S-modules 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-modules 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
2.3.126 status register: A register in an S-module by means of which current operating conditions of the Smodule (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 MTM-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 called 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 signicant bit is labeled bit 15 and the least signicant bit is labeled bit 0.
NOTEWhen a word of data is embedded in a MTM-Bus packet, bit <0> 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 Architecture. IEEE Std 1149.1-1990, IEEE Standard Test Access Port and Boundary-Scan Architecture (Includes IEEE Std 1149.1a-1993). IEEE Std 1149.1b-1994, Supplement to IEEE Std 1149.1-1990, IEEE Standard Test Access Port and Boundary-Scan Architecture. SAE Avionics Draft Standard AS4765, SAE Avionics TM-Bus Interoperability Standard, Revision 1.2, Nov. 1994.3
2IEEE
publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA. 3SAE publications are available from the Society of Automotive Engineers, 400 Commonwealth Drive, Warrendale, PA 15096, USA.
2-10
IEEE Std 1149.5-1995
3. MTM-Bus architecture
This clause denes 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.
3.1 MTM-Bus signals and interconnection of MTM-Bus modules via these signals
3.1.1 Specications Rules (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.
NOTESince 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 conguration (i.e., all drivers/receivers for each of the four signals shall share a single physical connection as in gure 3-1).
M-module
S-module
S-module
Master Data (MMD) Slave Data (MSD) Clock Source Pause Request (MPR) Control (MCTL) Clock (MCLK) NOTEThe 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-1Backplane MTM-Bus signals
3-1
IEEE Std 1149.5-1995
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 allow access to the full range of mandatory features of this Standard. The ve signals that make up the MTM-Bus are shown in gure 3-1. The MPR signal is a recommended signal that can be used to simplify the use of the bus in a system composed of modules having a wide range of operational speeds MCTLThe M-modules link-layer protocol uses the MTM-Bus Control signal to force data transfer operations over the MTM-Bus MMD and MSD signals. When the MCTL 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. MMDThe MTM-Bus MMD signal is used to serially transfer control or data from the M-module to Smodules. Whether the value of the MMD signal is intended to convey control or data is dependent upon the M-modules Master Controller state. MSDThe 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 period between the transmission of messages. MCLKThe MTM-Bus MCLK signal is used to synchronize the transfer of data between modules on the MTM-Bus. All other MTM-Bus signals change value only at the rising edge of the MCLK signal, and MTM-bus modules capture these other signal values only at the falling edge of the MCLK signal. MPRThe MTM-Bus MPR signal is used so that addressed S-modules may request the M-module to expand the pause between packet transfers during transmission of a message. This mechanism can be used to eliminate errors caused by the M-module sending packets too fast for a receiving S-module or by an S-modules 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 Mmodule 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.
3.2 General architecture and MTM-Bus mastership

3.2.1 Specications Rules (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
IEEE Std 1149.5-1995
3.2.2 Description The basic bus topology is shown in gure 3-2. In this diagram, a single M-module is depicted with a multidrop 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 dene 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.
Current M-module
S-module 1
S-module 2
S-module 3
S-module 250
NOTEMTM-Bus topology allows for a single M-module and up to 250 S-modules.
Figure 3-2MTM-Bus topology Should system diagnostic routines detect a malfunction in the M-module of a particular implementation of the MTM-Bus, system software may recongure the system by deactivating the current M-module and making a Master-capable S-module the new M-module. If a systems 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 Specications 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 manufacturers documentation a description of the mechanism by which that address is, or shall be, dened. (b) In a given MTM-Bus implementation at a given time, no two S-modules connected to that MTMBus may have the same module address.
NOTEThis rule implies that generic or off-the-shelf S-modules have to have one or more module addresses that can be xed by an user during assembly of a system (e.g., by the operation of switches or by programming).
(c) An S-modules module address shall be accessible to (i.e., readable by) the MTM-Bus interface circuitry of that module.
3-3
IEEE Std 1149.5-1995
(d) 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 error at the start of the current message contains either the S-modules module address, the broadcast address (FB HEX), or the multicast address (FC, FD, FE, or FF HEX) corresponding to the modules current multicast group (9.2; 16.5.1a).
(ii) The given S-module is unable to determine its module address unambiguously; and the HEADER packet received without detection of an error at the start of the current message contains either the amnesia address (FA HEX), the broadcast address (FB HEX), or commands addressed to the multicast address (FC, FD, FE, or FF HEX) corresponding to the Smodules current multicast group.
NOTEIt 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 HEADER packet (5.2.1; 11.5.1) or a State Sequence Error (7.1; 11.6.1) is detected.
(e) At the time a system including an MTM-Bus implementation is powered up, no S-module shall be addressed. (f) An S-module shall be considered uniquely addressed only after (i) a HEADER packet has been received that contains the S-modules module address, and the Smodule is able to determine its module address unambiguously;
(ii) a HEADER packet has been received that contains the amnesia address, and the S-module is not able to determine its module address unambiguously (and is therefore responding to the amnesia address (3.3.1d(ii); 3.3.1h).
NOTEDespite the fact that there may be multiple S-modules that can be addressed by the amnesia address, they all will behave as if they are uniquely addressed. In particular, they will return data if so required by a command addressed to FA HEX.
(g) An S-module shall respond to commands when and only when it is addressed.
NOTES 1This rule (taken together with 3.3.1d) implies that an S-module that can determine its module address unambiguously can never execute commands sent to the amnesia address (FA HEX). 2An S-module may take its MTM-Bus interface off-line during Start-up Built-In Test (SBIT) (18.2.1g) 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.
Recommendations (h) An S-module should be able to detect the condition of being unable to determine its module address unambiguously.
NOTETo utilize the safety features supplied by the amnesia address, this recommendation has to be implemented. 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 detected had the capability of 3.3.1h and the amnesia address been specied at the time and implemented. Alternative methods of addressing 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
IEEE Std 1149.5-1995
(i) The format/encoding 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.
NOTEFor example, to increase the probability of an S-modules detecting an error in the accessing of its module address, the module manufacturer could add an additional, parity bit to the module address.
(j) 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).
NOTEDetails of the manner in which an S-modules module address is programmed have to be fully documented by the modules manufacturer (22.1.1b).
Permissions (k) Module addresses may be implemented by a variety of means, including (i) on-module rmware
(ii) jumper wires (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 multicast 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 amnesia address in the most recently transmitted HEADER packet. Whether an S-module is addressed or uniquely addressed inuences 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 Smodule in question can respond only to commands sent to the amnesia address (FA HEX) or to any command sent to the broadcast address or the address of the S-modules 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 (11.7.1) can (at least sometimes) reduce the number of modules that remain addressed after ACKNOWLEDGE 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 segregated in one multicast group. Then this groups 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 1149.5-1995
equivalent to the broadcast address from the outset and simply remove amnesiac modules to another multicast 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-modules unique module address may be provided to the MTMBus test interface on the S-module by a variety of means including rmware, 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-modules MTM-Bus test interface will be able to detect the occurrence of single bit address faults and, consequently, will not respond to another S-modules address in the event of such a fault.
3-6
IEEE Std 1149.5-1995
4. MTM-Bus Physical Layer requirements

The MTM-Bus Physical Layer dened in this clause includes the denition of the electrical and timing requirements for the MTM-Bus signals. Precise electrical and timing requirements are not specied to allow for selection of bus transceivers most appropriate to a specic 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 designer/manufacturer of modules to separate the requirements for M-modules and S-modules.
4.1 Physical layer requirements independent of module type

4.1.1 Specications Rules (a) All MTM-Bus signal drivers, excluding the 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.
NOTEThe MTM-Bus signals MCTL, MMD, MSD, and MPR may collectively use active-low/negative logic levels on the backplane. Such an implementation may be necessary in some technologies to obtain a logical-OR operation.
(b) 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 insufciently powered for normal operation.
NOTEThis specication 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 operation 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 (TTL), backplane transceiver logic (BTL), and emitter coupled logic (ECL). The selection of a specic logic family may be inuenced by
4-1
IEEE Std 1149.5-1995
the length of the backplane, the number of expected loads, the bus frequency, noise immunity, cost, power, and available power supplies. Logic levels: This MTM-Bus Protocol Standard does not provide detailed electrical and timing parameters for the module. 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 transition. The MCLK signal has to make a clean transition through its threshold region to avoid inadvertent data driving or latching.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.
4.2 M-module Physical Layer requirements

4.2.1 Specications Rules (a) The MMD and MCTL signal drivers of an M-module shall be active continuously during operation of the MTM-Bus. (b) An M-module shall provide collision/error 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 Ms 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.1a) is resulting in a logic one value for the signal. (c) The M-module shall have the capability to detect 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
IEEE Std 1149.5-1995
4.3 S-Module Physical Layer requirements

4.3.1 Specications Rules (a) S-modules shall provide collision/error detection circuitry on the MSD signal connection. The relevant circuitry in a given module, M, shall detect cases in which Ms 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.1a) is resulting in a logic one value for the signal.
NOTECollision-detection circuitry plays a key role in the Contend for Bus (16.4.1) and Verify BMR (16.12.1) sequences.
(b) The collision/error detection function on the MSD signal of a currently addressed S-module shall be enabled to set the SDF bit of the Bus Error register and release the MSD signal (11.7.1a) 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).
NOTETiming constraints on collision-detection circuitry are implied by 11.7.1a. Namely, it has to be possible to detect a collision and release the MSD signal before the S-module in question can transmit another bit on MSDbefore the rst 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 gure 4-1, collision detection 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 gure 4-2, the component that provides support 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 command (16.4.1)], 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-modules Bus Error register (9.3).
4-3
IEEE Std 1149.5-1995
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.1g).
Output Enable MTM-Bus Output Signal EN 1D C1 The signal indicating that a collision has occurred is captured on the falling edge of the MCLK signal immediately following the rising edge of that signal that gave rise to the collision. System Pin
=1
&
1D C1
MCLK Collision
NOTEThis example circuit compares the logic value being driven with the logic value currently on the bus. A box containing =1 is the IEEE standard symbol for an XOR gate.
Figure 4-1Collision detection
Driver/Receiver
Collision Detection, etc.
System Pin
MTM-Bus Interface Logic
Bus Interface Devices Logic Levels (no logical-OR required)
Backplane Electrical Levels (logical-OR required)
NOTESeparate off-the-shelf drivers and receivers can be used to customize a single MTM-Bus interface device for multiple Physical Layer protocols.
Figure 4-2Bus transceivers
4.4 MTM-Bus timing requirements

The following symbols are used in specifying timing parameters and as labels in gures 4-3 through 4-5: t0 t1 T1M T0
M
is the time that MCLK is logic 0 per cycle is the time that MCLK is logic 1 per cycle is the minimum operable t1 for an MTM-Bus module or MTM-Bus interface device, M is the minimum operable t0 for an MTM-Bus module or MTM-Bus interface device, M
4-4
IEEE Std 1149.5-1995
tLH tHL tc
is the duration of MCLK rising edge transition is the duration of MCLK falling edge transition is the MCLK cycle time (tLH + t1 + tHL + t0)
NOTEThe transition times tLH and tHL can be determined only for a given system. These times are not considered a part of t1 or t0 and have to be accounted for in the selection of tc.
TcM TLH THL tp

M M
is the minimum operable tc for an MTM-Bus module or MTM-Bus interface device, M is the minimum operable tLH for an MTM-Bus module or MTM-Bus interface device, M is the minimum operable tHL for an MTM-Bus module or MTM-Bus interface device, M is the maximum system backplane propagation and settling time
tcsM,N is the clock skew as measured between the MTM-Bus signal driver, M, and the MTM-Bus signal receiver, N M Tco is the clock-to-output time for an MTM-Bus signal driver, M TsM Th
M
is the set up time for an MTM-Bus signal receiver, M is the hold time for an MTM-Bus signal receiver, M
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 Specications Rules (a) The MTM-Bus Clock (MCLK) signal shall be a single-phase clock. (b) In the implementation of the MCLK signal, a logic one shall be the more positive of the two voltages; and a logic zero, the least positive. (c) The manufacturer of an MTM-Bus module or MTM-Bus interface logic, M, shall document TcM (minimum operable value for tc), T1M (minimum operable value for t1), and T0M (minimum operable value for t0). (d) An MTM-Bus module or MTM-Bus interface device, M, shall be compliant to this Standard for all values of tc, t1, and t0 where tc TcM, t1 T1M, and t0 T0M. (e) Stored-state devices contained in MTM-Bus interface logic shall retain their states indenitely 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) All 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 (gure 4-4), and TsM (gures 4-3 and 4-4).
4-5
IEEE Std 1149.5-1995
Recommendations (i) For any MTM-Bus signal driver, M, the module timing parameters TcoM, TsM, and ThM should be minimized.
NOTEThis will support performance maximization for an MTM-Bus implementation to which the given module is connected.
(j) In any MTM-Bus module, M, the module timing parameter T0M should be minimized.
NOTEThis 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 (k) The manufacturer of an MTM-Bus module, may impose maximum operable values for tLH and tHL. 4.4.2 Description To ensure race-free operation, a dual edge clocking approach is used in this Standard. As illustrated in gure 4-3, an MTM-Bus signal driver (M) transmits data onto the bus a clock-to-output time (TcoM) after the rising edge of MCLK. The data propagates and settles after the propagation and settling time (tp). The data have to be valid at the receiving MTM-Bus signal input (N) at least setup time (TsN) prior to the falling edge of MCLK, that may lead, in the worst case, MCLK at the driver by tcsM,N. The module sourcing the data have to retain valid data at its relevant signal output until the end of the interval in which the MCLK signal is at logic 0. For all MTM-Bus signal driver/receiver pairs (M, N) such that M may drive a signal received by N, the relevant system timing relationship is characterized by t1 >= TcoM + tp + TsN + tcsM,N
TcoM
1D C1 rising-edge triggered
bus signal with propagation delay
TsN
1D
tp
C1 falling-edge triggered
tcsM,N
MCLK clock source
NOTEAn MTM-Bus signal output drives new data on the rising edge of MCLK, and an MTM-Bus signal input latches data on the falling edge of MCLK.
Figure 4-3Data transfer A timing diagram showing the MCLK and another MTM-Bus signal waveform at both a transmitter and a receiver are illustrated in gure 4-4. To assess module hold requirements, consider the worst-case conditionthat in which the clock at the receiver (MTM-Bus module N) trails the clock at the driver (MTM-Bus module M) as illustrated in
4-6
IEEE Std 1149.5-1995
figure 4-5. The system parameter t0 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 characterized by t0 ThN + tcsM,N
tc t1 tLH
MCLK at Driver (M)
t0 tHL
Signal at Driver (M)
Signal at Receiver (N)
MCLK at Receiver (N)
TcoM
TsN tp
tcsM,N
NOTEThis timing diagram shows the transitions of MCLK and another 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 situationwhere 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-4Data 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 (1)], the worstcase system propagation budget [equation (2)], and the worst-case module hold time requirement [equation (3)] are not violated. tc max (TcX : X is a module or interface device connected to the bus) t1 max (TcoX + tp + TsY + tcsX,Y : X is a signal output and Y is a connected signal input) t0 max (ThY + tcsX,Y : X is a signal output and Y is a connected signal input) In addition, the system timing parameters cannot violate the worst-case module timing parameters. (1) (2) (3)
4-7
IEEE Std 1149.5-1995
t1 max (T1M : M is a module connected to the bus) t0 max (T0M : M is a module connected to the bus) tc max (TcM : M is a module connected to the bus) As long as the system MCLK waveform parameters t1, t0, 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.
t0
MCLK at Driver (M)
Signal at Driver (M)
DATA BIT i
DATA BIT i1
Signal at Receiver (N)
DATA BIT i
DATA BIT i1
MCLK at Receiver (N)
t csM,N
T hN
NOTEThis 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 time situation. In this case, the clock at the receiver trails the clock at the source, propagation delay is zero, and clock to output delay for M is zero. The time t0 has to equal or exceed the sum of the clock skew and the hold time of N.
Figure 4-5Hold time requirement
Performance requirements: Although minimum performance requirements for an MTM-Bus module, M, are not specied, it is recommended that T1M and T0M 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 T1M and T0M requirements are met. Integration risk: All MTM-Bus timing relationships involve t1, t0, and tc. Thus decreasing the MCLK frequency (thereby increasing t1, t0, 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.
NOTEThe 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, NtcsM,Nhas to be controlled to avoid latching data from a signal that is in transition. This condition is characterized by tcsM,N 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 timing constraints may always be alleviated by increasing t1 or t0 (at the cost of reducing MTM-Bus bandwidth).
4-8
IEEE Std 1149.5-1995
Interoperability: Because this Standard addresses module timing parameters while leaving the system parameters exible, 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.
NOTEThe 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.1e. 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 status/error 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
4-10
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.1k, 6.1.1o, 6.1.1p, 8.3.1f, and clauses 12 through 20.
5.1 Requirements applicable to all packets

5.1.1 Specications Rules (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 <0> of each packet shall contain the packet parity bit. (c) The parity of each packet shall be odd.
NOTEThe modulo-2 sum of the bits in a packet (bits <16..0>) has to be 1.
(d) Each packet shall be serially transferred, msb rst. (e) Each packet shall be of one of the following types: HEADER packet, ACKNOWLEDGE packet, PACKET COUNT packet, DATA packet, or NULL packet.
5.2 HEADER packet requirements

5.2.1 Specications Rules (a) The HEADER packet shall consist of the Module Address, Command, Acknowledge request, and parity elds as shown in gure 5-1. (b) The Module Address eld shall be eight bits in length (bits <16..9>) and shall contain an S-module address (3.3.1). (c) The Command eld 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).
NOTEMTM-Bus commands are described in clauses 15 through 20.
(d) The Acknowledge Request eld shall be bit <1> 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 1149.5-1995
msb (16) (8 bits) Module Address eld
(9) (8) (7 bits) Command eld
(2)
(1) (1 bit) Ack Req bit
lsb (0) (1 bit) parity bit
Figure 5-1HEADER packet format 5.2.2 Description Precisely one HEADER packet occurs in each MTM-Bus message and is the rst 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 Specications Rules (a) The ACKNOWLEDGE packet shall consist of the Module Address, Module Status, and parity bit elds, as shown in gure 5-2. (b) The Module Address eld shall be 8 bits in length (bits <16..9>) and shall contain the address of the responding S-module. (c) The Module Status eld 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).
msb (16) (8 bits) Module Address eld
(9) (8) (8 bits) Module Status field
(1)
Figure 5-2ACKNOWLEDGE 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
IEEE Std 1149.5-1995
5.4 PACKET COUNT packet requirements

5.4.1 Specications Rules (a) The PACKET COUNT packet shall consist of a Packet Count eld and odd parity bit as shown in gure 5-3. (b) The Packet Count eld 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 eld shall indicate that the current message may contain any number of additional packets.
NOTENot 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; gure 7-1).
msb (16) (16 bits) PACKET COUNT eld
(1)
Figure 5-3PACKET COUNT packet format 5.4.2 Description If the Acknowledge Request bit is set in the HEADER packet 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; gure 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 ag 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 1149.5-1995
5.5 DATA packet requirements

5.5.1 Specications Rules (a) DATA packets shall consist of a Data eld containing sixteen (16) bits (bits <16..1>) and one packet parity bit (bit <0>) as shown in gure 5-4. (b) Binary data 16 or fewer bits long that is to be transmitted in a DATA packet shall be placed in contiguous bit positions in the DATA packet such that the least signicant bit (lsb) of the binary data is bit <1> of the DATA packet.
NOTEWhich bit of a bit string will be considered the lsb (msb) may be determined by the design(s) of the module(s) receiving a DATA packet or the design(s) of applications on that/those 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 specication of expected bit order in a given module, application, or system. Manufacturers are required to document port-specic 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.
(c) 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 signicant 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 signicant bits of the original data bit string;
(ii) the 16 least signicant bits of the binary data shall be transmitted in the rst transmitted DATA packet, and subsequent 16-bit-long substrings shall be transmitted (in order from least significant position to most signicant 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.1c(i)], then a nal DATA packet shall be transmitted. This nal DATA packet shall contain the substring S placed to ll the n least signicant bits of the DATA packets Data eld.
NOTEGiven a substring that is constructed from an original data bit string to be transmitted over the MTMBus, which bit of that substring will be considered the lsb (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 lsb in this context to emphasize the necessity of the clear specication of expected bit order in a given module, application, or system. Manufacturers are required to document port-specic 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.
(d) The contents and format of the DATA packets transmitted as part of a given message shall be as dened for the command code contained in the Command eld of the HEADER packet of that message.
NOTEFor example, see 17.1.1 (in particular, note documentation requirements) and the data transfers dened for the commands treated in clause 17.
Recommendations (e) Any bit positions within a DATA packet that do not contain a bit of a data bit-string being transmitted should be set to a logic 0.
5-4
IEEE Std 1149.5-1995
msb (16) (16 bits) DATA eld
(1)
Figure 5-4DATA packet format
5.6 NULL packet requirements

5.6.1 Specications Rules (a) A NULL packet shall be a DATA packet consisting of a 16-bit all-zeros eld and an odd parity bit as shown in gure 5-5.
NOTETo maintain odd parity, the parity bit of a NULL packet has to be set to logic one.
msb (16) (16 bits) 0000000000000000
(1)
Figure 5-5NULL 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.1a; 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 1149.5-1995
msb lsb Bit string to be transferred: 1110011010101011110001110101010101011110101 bits <0..15> Three DATA packets are required. msb DATA packet 1 lsb bits <16..31> bits <32..42>
1101010101100111 1
msb lsb
DATA packet 2
1010101011100011 0
msb lsb
DATA packet 3
0000010101111010 0
Figure 5-6Formatting a bit string of length greater than 16 for transmission in DATA packets
In gure 5-6, the string to be transferred is presented with lsb left-most. Notice that DATA packets have the lsb in the right-most position in the gure. This means that each set of sixteen bits beginning with the lsb has to have its apparent order reversed when formatting the bit string for transmittal on the MTM-Bus in a DATA packet. The number of bits in the sample bit string is 11 modulo 16. Therefore, ve logic zeros are added as padding in the third data packet; these padding bits are the ve high order bits in that packet. In each MTMBus packet a parity bit (odd parity) is the lsb of the packet.
5-6
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 contrast 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 nite state machine (fsm) described in the present clause. The M-module is controlled by programming of the M-module or a system application that governs the M-modules 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 specication clause, it will be helpful to the reader to review gures 6-2 and 6-3 and the text in 6.1.2. This gure 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 Specications Rules (a) The fsm of gure 6-1 (called the MTM-Bus Master Link Layer Controller or M-Controller) shall sequence the MTM-Bus message transmission behavior of an M-module.
NOTESystem 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 M1, 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 MController shall be in its POWERUP2_00 Master Controller state. (c) For a given Master Controller state, the logic values driven on the MCTL and MMD signals consequent 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 states 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.1i).
NOTENames 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 (gures 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.
NOTEThe M-module begins to drive new values of MCTL and MMD consequent to each rising edge of the MCLK signal (4.4.1e). Consequent to the next falling edge (4.4.1f) 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 MController to edges of the MCLK signal are presented in gures 6-2 and 6-3 with respect to a model of Mmodule internals depicted in gure 6-2. The internals of an M-module are unlikely to be observable. This Standard species external behavior of an M-module.
6-1
IEEE Std 1149.5-1995
M1, X, M3
M1, X, X
POWERUP2_00
M1, X, M3 M1, X, M3
M1, X, M3
IDLE_00
M1, X, X
not ( M1, X, M3)
M1, X, M3
XFER16_1X
M1, X, X
WAIT_00
This set of arcs, too small to label conveniently, represent transitions made in response to M1, X, X.
XFER15_1X
M1, X, X
XFER14_1X
M1, X, X
Next state of the M-Controller is determined by the values of 3 (three) variables: M1set if a collision is detected on MMD or MCTL. M2set if and only if (1) 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. M3set 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_1X. The conditions under which M1 and M3 are set are intentionally incompletely specied. In the case of M3, the only advantage to be gained may be convenience of design or speed of operation. In the case of M1, 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 M1, 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 dont 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 XFER12_1X to XFER3_1X are not shown, but would be drawn with connecting state transition arcs labeled, directed, and terminated identically to those shown for XFER13_1X.
XFER13_1X
M1, M2, M3 M1, X, X
XFER2_1X
M1, X, X
XFER1_1X
M1, X, X M1, X, X
XFER0_1X
M1, X, X
M1, M2, X
PAUSE_01
M1, X, X M1, M2, M3
EOM_00
M1, X, X
M1, X, X
NOTEMaster 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-1MTM-Bus Master Link Layer Controller state diagram
6-2
IEEE 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 gure 6-1 and the model of gure 6-2.
NOTEFigure 6-2 depicts an implementation that would achieve the desired behaviorespecially with regard to timing. See note under 6.1.1d. Output signal behavior is specied by 6.1.1c.
(f) An M-module shall transmit one and only one data bit in each of the seventeen M-transfer states.
NOTEThe M-transfer states are those Master Controller states the names of which begin with the characters XFER.
(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.
NOTEThe bits of a packet are transferred msb rst (5.1.1d).
(j) The M-module shall read the value on the MSD signal during each seventeen state sequence through the M-Controller beginning with the XFER14_1X Master Controller state and shall interpret the seventeen bits read as comprising a single packet transmitted by an S-module (or in the case of the execution 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 1All MTM-Bus signals are latched on the falling edge of the MCLK signal (4.4.1f). 2The last bit of a packet received by the M-module may be received in the M-Controllers XFER16_1X Master Controller state if the M-Controller remains in its PAUSE_01 Master Controller state for only one cycle of the MCLK signal. Otherwise, the last bit will be received while the M-Controller is in its PAUSE_01 Master Controller state. 3The 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 conguration error) and are transmitting identical packets or two or more S-modules are responding to the amnesia address [3.3.1d(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.
NOTERule 6.1.1a (gure 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.1c 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-Controller remain in its PAUSE_01 Master Controller state for a xed number of cycles (>1) of the MCLK signal. Also, see 6.1.1o.
(l) 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 1149.5-1995
(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 M1 and M3 (table 6-1) that are not explicit in gure 6-1.
NOTEInputs to the state variable M2 (gure 6-1) are completely specied.
Recommendations (o) The M-Controller should remain in its PAUSE_01 Master Controller state for at least four (4) consecutive cycles of the MCLK signal following the transmission of (i) every HEADER packet;
(ii) every message-terminating packet.

NOTES 1Following 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 errorsPacket Count (11.11.1), Port Transfer (11.8.1), and Parity (11.5.1) errorsand do requisite error processing 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 programming bits (PIE, IIE) in that S-modules 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-Controllers PAUSE Slave Controller state; and allowing some extra time for processing before termination of a message may be important.
Permissions (p) The M-Controller may remain in its PAUSE_01 Master Controller state for any number, n, of cycles of the MCLK signal where n is greater than or equal to 1.
NOTES 1The 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. 2The actual number of such cycles can be inuenced by an S-modules 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.
(q) 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.
NOTEThe 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 (prex) and an alphanumeric string of two characters following the underbar (sufx). With the
6-4
IEEE Std 1149.5-1995
exception of the WAIT_00 Master Controller state, the prex names the Slave Controller state (7.1; gure 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 sufx provides those values in the order <MCTL, MMD>.
Go to IDLE_00 or to EOM_00 Control Collision Detection M1 M3 M-Module Link-Layer Controller
M2
Output Data Control
Go to WAIT_00 Control MPR 1D MPR_LTCH
&
M-module Pause Control
M2 1D
IS_DATA_BIT
> C1
MSD 1D MSD_LTCH 1D
>C1
M-module Input Data
1D
> C1
MCLK
>C1 > C1
MSD_REG M-module Interrupt Processing
NOTES 1Figure 6-2 illustrates a model of the operation of M-module input latching and registration. A new value of MSD is driven 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 MTMBus. 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 directly to M-module Interrupt Processing circuitry when IS_DATA_BIT has the value logic 0 [6.5.1a]) and MSD_REG (connected directly to M-module data handling circuitry when IS_DATA_BIT has the value logic 1 [6.5.1a]) 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.1a; clause 11). Control of the M1, M2, and M3 state variable 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 registers receiving input data (M-module Input Data); and output data controls are omitted (although to reassume packet transmission 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 transitions of the M-Controller are unlikely to be directly observable in an M-module. This Standard specifies the observable behavior of an M-module. 2It 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-Controllers XFER1 Slave Controller state (figure 7-1) in order to be able to delay transmission of a subsequent packet.
Figure 6-2A 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-modules M-Controller
6-5
IEEE Std 1149.5-1995
MCLK
NOTEThe 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 second MSD input value is latched by the M-module (figure 62). The change of state of the S-modules 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) that the S-module is to generate during the new Slave Controller state (if any) is/are 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 set of MCTL/MMD values, and (4) the initial MSD signal value (originally driven consequent to the edge marked a) becomes accessible to M-module internals. The process is repeated for a-a, etc. Therefore, in this model, 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. On the other hand, it is not model-dependent that processing of a bit of S-module-originated data by the M-module may start two cycles of the MCLK signal after that bit is driven on the MSD signal by the S-module (figure 6-2), but not sooner. In this model, the values driven by an M-module while its M-Controller is in a given Master Controller state are driven onto the MTM-Bus roughly simultaneously with the M-Controllers entry into that Master Controller state. The change of state of the M-Controller is not observable and, in any given implementation might occur any time after the relevant MSD value has been registered and prior to the rising edge on which the state change occurs in this model. This Standard specifies the observable behavior of an S-module.
Figure 6-3Timing relationship of Master Controller state transitions to 1) M-module input value latching, 2) M-module registration of a latched MSD value, 3) S-module and M-module output driving, and 4) the MCLK signal
Figures 6-2 to 6-5 relate the edges of the MCLK signal to M-Controller state transitions and the driving of values on MCTL and MMD and the latching of the value on MSD. In addition, gure 7-4 illustrates the relationship in time between an M-module entering a given Master Controller state and an addressed S-modules state transition resulting from the values of the MCTL and MMD signals driven in that Master Controller state. The sequence is associated with edges of the MCLK signal as follows: a) 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 gure 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 gure 6-3), the values driven by the M-module are latched by the S-module receivers. At the rst 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 rst item of this list, that MCTL/MMD signal value pair will cause an addressed Smodules S-Controller to enter its XFER14 Slave Controller state (7.1.1; gures 7-3 and 7-4).
b) c) d)
6-6
IEEE Std 1149.5-1995
MCLK M. C. state MCTL MMD XFER1
PAUSE_01
XFER16_1X
XFER15_1X
XFER14_1X
XFER13_1X
S. C. state
XFER0
PAUSE
XFER16
XFER15
MSD
NOTEAs an example, a period of time is selected that coincides with the beginning of the transmission of a packet other 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 assume that change of Master Controller state occurs simultaneously with the change of values on the MCTL and MMD signals. We have arbitrarily shown 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-4Relationship of Master Controller states, Slave Controller states, packet transmission, and the MCLK signal
MCLK
MCTL HEADER packet bits
MMD
PACKET COUNT packet bits
MSD
ACKNOWLEDGE packet bits 2 cycles of the MCLK signal a a
NOTEDuring the transfer of a HEADER packet, the Slave Data (MSD) signal is released as no S-module yet knows to participate in the messagenone 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 XFER14_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 observable behavior of an M-module.
Figure 6-5HEADER packet and PACKET COUNT packet transfer
6-7
IEEE Std 1149.5-1995
The names and meanings of the three state variables controlling transitions of the M-Controller are provided in the large note of gure 6-1 and are used in that gure to encode state transition conditions. Transition through the M-transfer states is a simple ow with divergence caused only by the setting of the state variable M1 or by terminating a message after complete transmission of a packet by simultaneously clearing M1 and setting M3 (to cause transition between the PAUSE_01 and EOM_00 Master Controller states). Note that M1 has to be set as a result of detection of collision on the MCTL or the MMD signal (gure 6-1). A summary of the use of the three state transition variables is provided in table 6-1. Table 6-1Synopsis of use of state transition variables of the M-Controller
State variable M1 State variable use Mandated to be set in case of detection of collision on MCTL or MMD signals (6.4). May be used to cause immediate halt of message transmission under control of M-module or system applicationin circumstances other than collision detection. M2 Mandated to be set if and only if (a) MPR is asserted and the M-module is programmed to respond or (b) there is some other system-level or M-module internal reason for delaying transmission}. Mandated to be set when the next transition is (a) to EOM_00, (b) to IDLE_00 from some state other than EOM_00. Mandated to be cleared when the next transition is (a) to XFER16_1X or (b) to POWERUP2_00 from POWERUP2_00. May be used to cause other transitions permitted by gure 6-1.
M3
Implementations of responses to operating conditions that may cause the M-Controllers transition to its WAIT_00 Master Controller state are not addressed in detail by this Standard. Among the variable-affecting conditions controlling ow in the fsm of gure 6-1, detection of a collision and ability to respond to parity 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.1b; 4.2.1c; 4.2.1d; 6.2.1b; 6.2.1c; 6.3.1; 6.5.1; 8.2.1; 8.3.1). It is recommended (6.1.1o) that an M-module or the appropriate system application controlling an M-module hold the modules M-Controller in the PAUSE_01 Master Controller state for at least four cycles of the MCLK signal following transmission of the rst and last packets of a message. Clause 6.1.1k requires that this delay be possible in every M-module after every 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 overow 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 sufciently early so that it is possible for it to be detected by the M-module before transmission of the next packet begins.
6-8
IEEE Std 1149.5-1995
6.2 M-module send and receive parity requirements

6.2.1 Specications Rules (a) The M-module shall have the ability to be directed to transmit either HEADER or DATA packets having bad parity.
NOTEThis 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-moduleduring 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.1a). 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 1This Standard requires that an M-module be able to detect bad parity on a received packet (6.2.1b); 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 M1 (table 6-1) when a parity error is detected. The M-Controller has to remain in its PAUSE_01 Master Controller state long enough for the parity checking to be completed and the value of M1 to assigned. Setting M1 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 beyond the scope of the Standard. 2If 6.2.1e is implemented, 22.1.1b requires that the means of programming involved be fully documented by the manufacturer of the M-module.
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 Smodules parity checking circuitry. For example, the M-module might perform such a test as part of a poweron self-test sequence that tests each part of the interface thoroughly prior to beginning normal bus operations. The M-module may also send bad parity on HEADER packets to verify that S-modules ignore messages that begin with a HEADER packet that contains a parity error (8.1.1a and clause 11). When the M-module transmits a HEADER packet as shown in gure 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 participate in the message. Accordingly, the M-modules low-level bus interface circuitry has to be designed such that it doesnt 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
When the M-module detects bad parity in an S-module-transmitted 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 diagnose the cause of the bad parity (e.g., by using a test command such as the Data Echo Test command [16.11.1] or by resetting suspect S-modules using the Reset Slave Status command [16.3.1]). 6.2.1d requires that the M-module always transmits valid parity during every packet transfer (except when testing the S-modules 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 Specications Rules (a) An M-module shall be designed to be programmed (i) to respond to the MPR signal, i.e., maintain behavior as though (with regard to the model of gure 6-2) M2 were connected 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 state variable M2 (gure 6-1) equal to logic zero.
NOTEWhile this rule appeals to the model of gure 6-2, this is only a mechanism allowing this Standard to specify behavior of an M-module. This Standard species the observable behavior of an M-module.
Recommendations (b) The M-module should include a programmable means to be used to dene 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 specications), programmed permission for the M-module to respond to the assertion of MPR [6.3.1a(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.1c). 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 exibility 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 indenitely 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
IEEE Std 1149.5-1995
period. This timing function might operate off of a clock other than MCLK so that a fault on MCLK will not prevent notication of the system that a failure has occurred on the MTM-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.1a and gure 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 WAIT_00 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 Specications Rules (a) To detect interrupt requests from an S-module, the M-module shall be designed so that (following the model of gure 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 XFER15_1X, XFER16_1X, and PAUSE_01 Master Controller states if no packet bit from the S-module is to be read in the state in question in the present cycle of the MCLK signal.
NOTES 1Once S-module transmission of a given packet is completed, an S-module permitted to signal an interrupt in its S-Controllers 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-Controllers EOM and IDLE Slave Controller states may do so by assertion of the MSD signal. 2If an M-module is operating in such a manner that its M-Controller remains in its PAUSE_01 Master Controller 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-Controllers XFER15_1X Master Controller statewith 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 statesagain, in this case, new packet transmission 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 1149.5-1995
(b) The manufacturer of an M-module shall implement a means of programming the M-module (following the model of gure 6-2) to function in any of the following ways: (i) to respond to assertion of the MSD_LTCH signal (i.e., initiate servicing of a signaled interrupt) during Master Controller states listed in 6.5.1a;
(ii) to determine the timing and nature of the response to an interrupt; (iii) to ignore assertion of the MSD_LTCH signal during Master Controller states listed in 6.5.1a.
NOTES 1This 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. 222.1.1b requires that the means of programming involved in an implementation of 6.5.1b be fully documented 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 terms of cycles of the MCLK signal.
NOTEIt is not only important to be able to direct the M-module to respond or not respond to an interrupt. The designer of a system using the MTM-Bus, has to know how long the response may be expected to take.
Permissions (d) The programmability required in 6.5.1b 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 specied in 6.5.1a.
NOTE22.1.1a requires the manufacturer of an M-module to document all capabilities implemented in accord with 6.5.1d.
6.5.2 Description Clause 10 contains the specications governing the assertion of the MSD signal by an S-module for the purposes of signaling an interrupt. This Standard only species the times when an M-module has to observe the MSD signal for the purpose of detecting an interrupt. It is beyond the scope of this Standard to specify M-module or system responses to interrupts other than those error responses specied in clause 11.
6-12
IEEE Std 1149.5-1995
7. MTM-Bus Link Layer: S-module requirementsMTM-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 nite state machine (fsm) described in the present clause. Before beginning a review of the following specication clause, it will be helpful to the reader to review gures 7-3 and 7-4 and the text associated with them in 7.1.2. These gures 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 Mmodule. This Standard species the observable behavior of an S-module. 7.1.1 Specications Rules (a) The fsm of gure 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.
NOTEThe S-Controller of an unaddressed S-module makes all state transitions just as does the S-Controller of an addressed S-module.
(b) Precisely one state transition of the S-Controller shall occur in each cycle of the MCLK signal. (c) An S-module shall respond to values driven on the MMD and MCTL signals by behaving in a manner consistent with gure 7-1 and the model of gure 7-3.
NOTEFigure 7-3 depicts a model of S-module internals that would satisfy this requirement. The model of gure 7-3 is not intended to represent a desired or recommended implementation of S-module internal circuitry. That gure is used only to specify the external behavior of an S-moduleespecially with regard to timing.
(d) 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.
NOTEThe 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.
(e) 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.
NOTEIt is a convenient convention to speak of the data bit of the MMD/MCTL signal pair ultimately causing 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 stateaccording to the timing described in gure 7-4 and the accompanying 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 conveys data when the value of the MCTL signal is a logic 1.
7-1
IEEE Std 1149.5-1995
(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.
NOTEBeginning S-module packet transfer in the XFER16 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 (gure 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.1f 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.1f.
NOTEThe bits of a packet are transmitted msb rst (5.1.1d).
(h) An S-module that was addressed immediately prior to its S-Controllers entry into its EOM Slave Controller state shall still be addressed when its S-Controller is in the EOM Slave Controller state.
NOTES 1Since, once the M-module transmission of DATA packets of a given message is completed, it is the responsibility of the system-level application controlling the M-module to direct the M-module to send NULL packets while DATA packets are still expected back from an uniquely addressed S-module, the issue of S-module packet transmissions beyond the end of M-module packet transmissions does not arise. 2Since a State Sequence Error may be recorded by a transition of an S-Controller from its EOM Slave Controller 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 (11.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.

NOTEWhen an S-module is not addressed and its S-Controller is in its IDLE Slave Controller state, that Smodule cannot signal an interrupt unless the IIE bit is set in that S-modules 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.
NOTE7.1.1j denes the initialization of an S-modules S-Controller. NOTEState 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 rising edge (figure 7-4).
7.1.2 Description The transmission of data on the MTM-Bus is controlled by the M-modules asserting and releasing the Control (MCTL) and Master Data (MMD) signals. The registered values of these two control signals (as in the model of gure 7-3) controls the S-Controller state transitions as shown in gure 7-1. S-Controller state transitions may be modeled to occur on the rising edge of the MCLK signal consistent with 4.4.1e, 7.1.1b, and 7.1.1c (figures 7-3 and 7-4). From any Slave Controller state in the state diagram of gure 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
IEEE Std 1149.5-1995
<MCTL, MMD> = 1X or 01
POWERUP1
00
1X or 01
POWERUP2
00 00
IDLE
01 01 or 1X 0X 1X
XFER16
1X
00
ERROR
0X
XFER15
1X
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-modules Bus Error register will be set only if the S-module is addressed (table 9.4; 11.6.1).
0X
XFER14
1X
0X
XFER13
1X
0X Next State is determined by the values of the MCTL_REG, MMD_REG signals (gure 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 XFER3 are not shown, but would be drawn with connecting state transition arcs labeled, directed, and terminated.
XFER2
1X
0X
XFER1
1X
1X or 00
XFER0
01
01
PAUSE
00
1X
1X or 01
EOM
00
Figure 7-1MTM-Bus Slave Link Layer Controller state diagram
7-3
IEEE Std 1149.5-1995
POWERUP1 and POWERUP2 Slave Controller statesAn S-modules S-Controller is expected to enter the POWERUP1 Slave Controller state as a result of the S-modules power-up sequence (7.1.1j). One scenario for system start-up is that the M-module might be powered up rst 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-modules S-Controller enters its POWERUP1 Slave Controller state, the S-Controllers of all S-modules on the MTM-Bus will be in the IDLE Slave Controller 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 message 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 maintain 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. Consider the cases of single bit glitches: a) If the glitch is on MCTL, the transition to the XFER16 Slave Controller state will occur at least one cycle of the MCLK signal too early (with respect to the transmission of the next packet from the Mmodule). This will lead to a State Sequence Error 1) immediately (if MCTL is released after the glitch) or, 2) if a new packet transfer begins in the cycle of the MCLK signal following the glitch, at the end of the transfer of that packet. (In the latter case, note that the M-module will send one last bit of data after the S-modules S-Controller has left its XFER0 Slave Controller state.) If the glitch is on MMD, the improper state transition will be to the EOM Slave Controller state. Since we have assumed that the glitch 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.
b)
If condition b(i) were to occur and there were no EOM Slave Controller state, then the S-modules 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 XFER0 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) rst (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 XFER0 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 rst cycle of the MCLK signal in which the
7-4
IEEE Std 1149.5-1995
S-modules S-Controller is in its XFER0 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 (gures 7-2 and 7-4).
MCLK
MCTL
MMD
Bits of HEADER Packet
Bits of M-module Packet
MSD
Bits of S-module Packet 2 cycles of MCLK signal
NOTES-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-2Time 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 stateThe PAUSE Slave Controller state is the mechanism used to provide a minimum 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.1c; gure 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-modules holding MCTL released and MMD asserted. A Slave may signal an interrupt during the PAUSE Slave Controller state consistent with clause 10. ERROR Slave Controller stateThe 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=1, MMD=X) for more than the specied 17 consecutive cycles of the MCLK signal. The M-module transmits insufcient bits to make up a packetMCTL=1 with MMD=X for less than the specied 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 (gures 7-3 and 7-4) of the state transition controlling 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 (gures 7-3 and 7-4) of MCTL and MMD are both 0. This allows resynchronization of the M-module and S-module following 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 (11.6.1b). As a consequence, if the M-module is receiving a
7-5
IEEE Std 1149.5-1995
packet from an S-module when that S-modules S-Controller 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.
S-module Output Data Collision Detection
&
S-module Output Data Control
1D
MSD
> C1
&
IS_XFER_STATE S-Module Link Layer Controller MCTL 1D MCTL_LTCH 1D MCTL_REG 1D
> C1
MMD 1D MMD_LTCH
> C1
1D MMD_REG
>C1
1D
> C1
MCLK
>C1 > C1
S-module Input Data
NOTEFigure 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 labeled MMD_LTCH and MCTL_LTCH respectively. 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 XFER16 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-module 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 behavior of an S-module.
Figure 7-3A 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-modules S-Controller
7-6
IEEE Std 1149.5-1995
MCLK
NOTEThis diagram is an example of 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 implementation. 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 MCTL/MMD values is driven by the M-module. At the falling edge marked b, the second set of MCTL/MMD input values are latched by the S-module. The change of state of the S-modules S-Controller that depends on the values driven by the M-module at a occurs on the rising edge marked a. At this same time, (1) the output that the S-module is expected to generate during the new state is driven, (2) the second set of values driven by the M-module is registered by the S-module, and (3) the Mmodule drives the third set of MCTL/MMD values. The process is repeated for a-a, etc. Therefore, in this model, 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. In this model, 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-Controllers entry into that Slave Controller state. A change of state of the S-Controller may not be directly observable and, in any given implementation 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 observable behavior of an S-module.
Figure 7-4A 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
7.2 S-module interface logic requirements

7.2.1 Specications Rules (a) Physical layer requirements shall be met by an S-modules MTM-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.
NOTEIn addition, 15.1.1 requires that the implementation of Core class commands in a given S-module be considered 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 application of an S-module: 11.2: Self-Test Failureapplication 11.4: Data Overrun Errorapplication 11.5: Parity Errorinterface logic 11.6: State Sequence Errorinterface logic 11.7: Collision Responseinterface logic 11.8: Data Port Transfer Errorsapplication 11.9: Command Sequence Errorinterface logic 11.10: Illegal commandinterface logic (for Illegal command) and application for unimplemented /reserved commands 11.11: Packet Count Erroreither 11.12: Command Resource Errorapplication 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-modules MTM-Bus interface logic (15.1.2). An S-modules application logic may need to be aware of activity in [the state of (here not limited to mean Slave Controller state of)] that S-modules MTM-Bus interface logic (14.1.1e; 14.1.2; 15.1.2).
7-8
IEEE Std 1149.5-1995
8. MTM-Bus Link Layer: S-module requirementsgeneral communications

8.1 S-module send and receive parity requirements
8.1.1 Specications Rules (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; gure 7-1; 9.3.1; 9.3.2; 11.6.1b) or when the S-module is complying with a Data Echo Test command (16.11.1) and echoing a packet that had bad parity as received.
NOTESince 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 Mmodule has a chance of having bad parity.
8.2 S-module MSD signal general requirements

8.2.1 Specications Rules (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 participating in a Contend for 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 specications 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 rst 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) command. An S-module is required to assert the MSD signal upon the entry of that S-moduless 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-modules 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 stateunder normal operating conditions. When an S-Controller has entered its ERROR Slave Controller state, the S-module containing that S-Controller cannot be assumed to be tracking MTM-Bus activity and cannot predict when the SController 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
always asserts the MSD signal while in its S-Controllers 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-modules 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 Specications Rules (a) An addressed S-module in which the MPR signal (4.3.1c) is implemented shall indicate its readiness or lack of readiness to continue message transmission by (respectively) releasing or asserting the MPR signal. (b) An S-module that is not addressed shall not assert the MPR signal. (c) An S-module that is asserting the MPR signal shall release the MPR signal upon entry of that Smodules S-Controller into its EOM Slave Controller state. (d) During and immediately following the transmission of any packet other than a HEADER packet, if an S-module releases the MPR signal while the S-Controller is in any of the following Slave Controller states (XFER1, XFER0, PAUSE, EOM, and IDLE), the S-module shall not assert MPR before the S-modules S-Controller next enters its XFER16 Slave Controller state. (e) Immediately following the transmission of a HEADER packet, if an S-module releases the MPR signal while (i) its S-Controller is in its EOM or IDLE Slave Controller state
(ii) its S-Controller is in its PAUSE 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-modules MMD input, then the S-module shall not assert MPR before its S-Controller next enters its XFER16 Slave Controller state.
NOTEIf sufcient cycles of the MCLK signal are allowed after transmission of a HEADER packet and before the next M-module packet transmission of the 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 transmission 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 modules S-Controllers 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 1Consider 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
IEEE Std 1149.5-1995
quence of 6.1.1 and gures 6-1, 6-2, and 6-3 that, if the MPR signal is to be asserted by an S-module following the M-modules transmission of a given packet, then the S-module has to validly drive a logic one on the MPR signal while that modules S-Controller is in its XFER1 Slave Controller state during the transmission of the given packet. 2Consider the case in which an M-Controller is designed/programmed to remain in its PAUSE_01 Master Controller state for 4 cycles of the MCLK signal after transmission of a HEADER packet (6.1.1o). It is a consequence of 6.1.1 and gures 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-modules 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
b MCLK a MCTL
b b b b(4) b(5) b(6) b(7) a a a a(4) a(5) a(6) a(7) a(8)
MMD
MSD
c
MPR one MCLK cycle MPR has to be asserted here in order to prevent a subsequent packet transfer from being started. two MCLK cycles New packet transmission begins.
NOTEIf an addressed S-module needs to request additional time for its S-Controller to remain in its PAUSE Slave Controller 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 7-4, 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-modules 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 a(6). Once the S-modules S-Controller is in an S-transfer state, it is recommended that the module reassert the MPR signal; this occurs 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 PAUSE_01 Master Controller state at a and its XFER16_1X Master Controller state at a(6). The S-module in this example enters its XFER1 Slave Controller state at a, its PAUSE Slave Controller state at a(4), and its XFER16 Slave Controller state at a(8).
Figure 8-1MPR 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 XFER0 Slave Controller state of that modules S-Controller to request of the M-module that the S-Controller be held in its PAUSE Slave Controller state, as shown in gure 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-modules 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
nated in this manner, then for as long as the relevant S-modules 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-modules 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 Mmodule following the forced packet transfer. If an S-modules 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 signal. 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 ow 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
IEEE Std 1149.5-1995
9. MTM-Bus Link Layer: S-module requirementsstatus registers

An S-module records the following information in two or more status registers: certain programmable operating parameters the occurrence of certain application-specic events the occurrence of events requiring the sending of an interrupt to the M-module other ags, 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) identies specic types of errors that may be the cause of an interrupt. Such errors include errors in MTM-Bus operation S-module operation packet contents The Module Status register (9.4) may contain both status 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 minimum requirements for such registers are fullled.
9.1 S-module status registersgeneral requirements

9.1.1 Specications Rules (a) Each S-module shall contain in its interface logic its own (unshared) Slave Status register as described in 9.2. (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 ve MTM-Bus signals). (d) If 9.1.1e is implemented, reading of data from the data backup means dened in 9.1.1e shall not cause the alteration of that data as recorded in that backup means.
NOTEWhen 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 ambiguity. However, if for some reason a register has to be reread in such a situation, the original data would be lostif 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
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 registers contents, the data read should be preserved by a means that allows repeated reads of the data via a port as dened in 21.9.
NOTEIt is reasonable to assume that the preservation of data in a register as described in the present recommendation occurs prior to the scanning of data from the register. Reading of data from the data backup means required if 9.1.1e 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.1h and 9.5.1 should be supported in the manner recommended for Slave Status, Bus Error, and Module Status registers in 9.1.1e. 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 data within a Read Status message, a Parity Error is detected on a packet received by the M-module. Supposing that the M-module were responding to a sufciently critical interrupt, it would be very important to be able to reread the register the contents of which were apparently garbled in the packet in question. However, this requires some functionality different from that supplied by the Read Status command. 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 ambiguity. If for some reason a register has to be re-read in the above 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 dened as is recommended (21.8). Out of continued concern for security (i.e., consistent with the motivation behind 9.1.1e), The contents of these resources should not be altered when they are read. The only Data Transfer class command given access to the port of such a resource has to be the Read Data command.
9.2 Slave Status register

9.2.1 Specications Rules (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 dened in table 9-1. (b) Power-up and reset values for the bits of the Slave Status register shall be as specied in table 9-2.
NOTEPower-up values for all MTM-Bus Status registers are the same values specied to be in those registers as a result of executing the Reset Slave Status command (16.3.1).
9-2
IEEE Std 1149.5-1995
Table 9-1Slave Status register bit denitions

PB 8 (msb) 7 RB 7 Name Module Fail Status Mnm MFS 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 Smodule is executing its power-up sequence, which may include self-test.
NOTEThe 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.
Slave Busy
BSY
Event Occurrence
EVO
An application-related condition requiring an interrupt has occurred [may be elaborated in the Bus Error register (bits <12..15>), Module Status register or additional status registers]. An error has been detected (elaborated in the Bus Error register). This bit and the following (MSB0) together encode the modules 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 not addressed, the S-module may generate an interrupt 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.
NOTEThis bit is set on power-up (table 9-2).
5 4 3 2
4 3 2 1
Bus Error Multicast Select Bit 1 Multicast Select Bit 0 Pause Interrupts Enabled
BSE MSB1 MSB0 PIE
1 (lsb)
Idle Interrupts Enabled
IIE
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 Smodules 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.
NOTEResponse to self-test failure is treated in 11.2.1 and 18.1.1b.
(f) Except as required by 9.2.1bd 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 1149.5-1995
Table 9-2Values of Slave Status register bits at power-up and after reset
PB 8 (msb) 7 6 5 4 3 2 1 (lsb) Key: RB 7 6 5 4 3 2 1 0 Mnm MFS BSY EVO BSE MS1 MS0 PIE IIE 0 0 0 0 0 0 0 1 Value at power-up and after reset*
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.1a; 9.3.1e; table 9-4) in the Bus Error register equals a logic 1.
NOTENot all bits in the Bus Error register are error bits. The BMR bit is an example of a non-error bit, and its value is not input to the logical OR required by 9.2.1g. User-dened 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-module shall be set if a logical OR driven by both of the following: (i) all error bits of the Module Status register (9.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 1Other bits of the Module Status register or of additional registers may drive the logical OR required by this rule (9.2.1j; 9.2.1k). 29.2.1h(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-modules returning an ACKNOWLEDGE packet (5.3.1).
9-4
IEEE Std 1149.5-1995
Permissions (j) The logical OR driving the BSE bit in the Slave Status register of a given S-module (9.2.1g) may be driven by (i) user-dened 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-modules manufacturer. (k) The logical OR driving the EVO bit in the Slave Status register of a given S-module (9.2.1h) may be driven by (i) user-dened 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-modules manufacturer. (l) The logical OR driving the EVO bit in the Slave Status register of a given S-module (9.2.1h) may be driven by any bits of additional registers (9.5) that are documented to do so by the S-modules manufacturer. 9.2.2 Description Table 9-2 denes 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 dened 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 dened 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 (18.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 register have to be set at the initiation of a self-testing sequence (9.2.1c). 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.1e). 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.1b; table 9-2). Slave Busy bit When set, the BSY bit (bit <6>) indicates that the addressed S-modules 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
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.1e; 11.2.1a). Event Occurrence bit When set, the EVO bit (bit <5>) 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.1a) in the Module Status register will cause the EVO bit to be set (9.4.1b). Setting the EVO bit will cause an interrupt to be generated consistent with 10.1.1. Note that application-dened bits of the Bus Error register (bits <12..15>), Module Status register and/or additional status registers may also be input to the logical OR that sets the EVO bit, as detailed in a given S-modules specications. 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-specic 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-modules specications. Multicast Select bitsThe MS1 and MS0 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 dened for the Multicast Select 0, 1, 2, 3 commands (16.5.1). Table 9-3Multicast select groups and their addresses
MS1 0 0 1 1 0 1 0 1 MS0 Multicast Select group 0 1 2 3 Multicast address HEX FC HEX FD HEX FE HEX FF
Pause Interrupts Enabled bit An uniquely addressed S-module may always signal an interrupt when it S-Controller is in its PAUSE Slave Controller state. The PIE bit is relevant to interrupt operation while an S-module is addressed via multicast or broadcast and when an S-module 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 (gure 7-1 and table 10-1) when the S-module is addressed during a broadcast 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 dened in 10.1.1. The PIE bit is set as dened for the Enable Pause Interrupts command (16.7.1). The PIE bit is cleared as dened for the Disable Pause Interrupts command (16.9.1). Idle Interrupts Enabled bit When set, the IIE bit (bit <0>) 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 (gure 7-1; table 10-1). This interrupt capability is further dened in 10.1.1. The IIE bit is set as dened 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 IIE bit is cleared as dened 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 rst data packet in response to the Read Status command (16.1.1). When the Slave Status register state is returned as
9-6
IEEE Std 1149.5-1995
part of the ACKNOWLEDGE packet, the data in the Slave Status eld of that packet will not reect any status changes due to the command received in the HEADER packet of the current message.
9.3 Bus Error register

9.3.1 Specications Rules (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 dened in table 9-4. (b) Power-up and reset values for Bus Error registers shall be as specied in table 9-5.
NOTEPower-up values for all MTM-Bus Status registers are the same values specied to be in those registers as a result of executing the Reset Slave Status command (16.3.1).
(c) Bus Error register bit <11> shall be reserved for future denition by this Standard and, after being cleared at power-up according to 9.3.1b, shall remain at a logic 0. (d) All unimplemented user-dened bits, after being cleared at power-up according to 9.3.1b, shall remain at a logic 0. (e) If 9.3.1h is implemented, then the user-dened bit in question shall be an input to the logical OR forming EVO. Permissions (f) Any user-dened bit (bits <15..12>) may be used to indicate application-specic MTM-Bus related errors. (g) Any user-dened bit (bits <15..12>) may be used to indicate module-specic 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.1d; 21.10.1f through 21.10.1h; 21.10.1n), an indicator for the occurrence of a trigger event may be implemented as a user-dened bit in the Bus Error register. (i) The indicator for completion of an S-modules 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).
NOTETo know that a self-test has completed without detection of a failure, two indicators are requiredthe fact that the MFS bit of the Slave Status register has not been set is insufcient 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.1e.
9.3.2 Description The Bus Error register identies the type of error that has caused a given S-modules 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
Table 9-4Bus Error register bit denitions

PB 16 (msb) 15 14 13 12 11 RB 15 User-dened Name Mnm
Meaning (when set unless otherwise stated) User-dened
14 13 12 11 10
User-dened User-dened User-dened Reserved Broadcast/Multicast Received
BMR
User-dened User-dened User-dened Undened A previously transmitted broadcast or multicast HEADER packet was received without error. Shall be (shall have been) set when an addressed S-modules 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 unless that HEADER packet included the command code of the Verify BMR command and the denition of the command (16.12.1) requires the bit not to be set. Shall not be set during a broadcast or multicast message except as just specified, above. NOTES
1Following successfully transmitted messages conveying simple commands (12.1.1; gure 12-1) that reset an Smodule, this bit will not be set because the execution of a command occurs after the setting of the BMR bit (14.1.1f). 2To use the BMR bit to check for successful transmission of a particular broadcast or multicast HEADER packet, the BMR bit has to be cleared after the end of transmission of any previous broadcast or multicast message.
Key:
9-8
IEEE Std 1149.5-1995
Table 9-4Bus Error register bit denitions (Continued)

PB 10 RB 9 Name Slave Data Fault Mnm SDF Meaning (when set unless otherwise stated) 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-modules S-Controller was in one of its Stransfer states. The S-module was not responding to either the Contend for Bus or the Verify BMR command. A resource required to execute a previously received command 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 (11.12.1). Shall not to be used to indicate partial completion of a command. 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 different 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 consisting only of a HEADER packet in which the Acknowledge Request bit was set and in which the Command eld 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 eld of that packet contained the command code of either the Contend for Bus (16.4.1) or the Verify BMR (16.12.1) command.
NOTEWhen the Acknowledge Request bit is set in a HEADER packet and a single glitch on the MCTL signal causes an S-modules 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 (gure 7-1).
Command Resource Unavailable
CRU
Incorrect Packet Count
IPC
7 6 5
6 5 4
Illegal Port Selected Port Transfer Error Command Sequence Error
IPS PTE CSE
A logical port address to which data was directed is not supported (11.8.1a). A selected port has reported a Port Transfer Error (11.8.1b; 11.8.1c). A critical control command was received, but was not immediately preceded by an Enable Module Control command (11.9.1; 16.10.1).
Key:
9-9
IEEE Std 1149.5-1995
Table 9-4Bus Error register bit denitions (Continued)

PB 4 RB 3 Name Illegal Command Mnm ILC Meaning (when set unless otherwise stated) An illegal command was received (11.10.1) an unimplemented command, a Reserved command, or the Illegal command (16.17.1). A Parity Error was detected on a received packet (11.5.1). Data was transmitted to the S-module when the S-module was not ready to receive data (11.4.1). The S-modules S-Controller entered its ERROR Slave Controller state (7.1.1; gure 7-1; 11.6.1).
3 2 1 (lsb) Key:
2 1 0
Parity Error Data Overrun Error State Sequence Error
PRE DOR SSE
See clause 11 for information on error handling including requirements on manufacturer documentation concerning when Bus Error register bits are set (11.1.1). User-dened bits in the Bus Error register may be used for module specic status indicators. Table 9-5 denes the state of the Bus Error register at power-up and reset. The set of MTM-Bus commands dened in this Standard that always result in a reset of the Bus Error register are as follows: Reset Slave Status command (16.3.1) Reset Module with SBIT command (18.2.1) Reset Module without SBIT command (18.3.1) 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 two or more packets are transmitted by an S-module during a Read Status message, then the Bus Error register will be cleared as a result. User-dened bits Bits<15..12> of the Bus Error register may be used for module or application-specic purposes. A user-dened bit may record an occurrence that should be agged as an error or may be used as a module-specic status indicator. These bits may cause the BSE bit 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 set/clear them) has to be documented in an S-modules manufacturers specications. If these bits are not used, they have to be set to logic 0 at power-up and remain at logic 0. Reserved bit Bit <11> is reserved for future denition 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 <10>), 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 situation 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
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 participate in the message (11.3). Despite error-free multicast or broadcast transmission of a HEADER packet, the BMR bit of an addressed S-modules Bus Error register will be cleared after the execution of simple commands (12.1.1; gure 12-1) that reset addressed S-modules (14.1.1f). Error bitsThe 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-modules Slave Status register is set by the output of a logical OR of the error bits and, optionally, user dened 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 species requirements on manufacturers of S-modules with regard to documentation 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 summarizes 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 awed transmission 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-module is 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-modules 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.
NOTEThis situation may occur during an S-modules attempt to execute a Module I/O Control and Test class, Module Initialization and Self-Test class, or User class command (15.1).
c)
The S-module receives a Data Transfer class or Module I/O 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-1), the Port Identier 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 identied in the PACKET COUNT packet (11.11.1). The IPC bit is set after the S-modules 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-modules S-Controller enters its XFER16 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
Illegal Port Selected bit The IPS bit (bit <6>), when set, indicates to the M-module that the Port Identier contained in the PORT ID packet (17.1.1a) of a Data Transfer class command message is not supported by the S-module (11.8.1a). A list of all ports supported by a module will be provided in the module documentation. The IPS bit is set following transmission of the PORT ID packet, if the Port Identier contained therein is invalid. Port Transfer Error bit The PTE bit (bit <5>), 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 selected port has detected an error. The S-modules S-Controller enters its XFER16 Slave Controller state, and the S-module is not prepared to transmit a non-NULL DATA packet although one would ordinarily be expected at the time (11.8.1c) 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-module 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: a) b) The S-module received a command requiring the Enable Module Control (EMC) command (16.10.1), without receiving the EMC command in the immediately preceding message (11.9.1b). The S-module received the EMC command followed by a command that did not require the EMC command (11.9.1a).
Illegal Command bit The ILC bit (bit <3>), when set, indicates to the M-module that the S-module received the Illegal Command (16.17.1), a Reserved command, or an unimplemented command (11.10.1). The ILC bit is set following receipt of a HEADER packet containing the Illegal command. Parity Error bit The PRE bit (bit <2>), when set, indicates to the M-module that the S-module received a DATA packet, NULL packet, or PACKET COUNT packet with incorrect parity (11.5.1b). Note that the PRE bit is not set when the S-module receives a HEADER packet with incorrect parity (11.5.1a). Data Overrun Error bit The DOR bit (bit <1>), when set, indicates to the M-module that the S-module was unprepared to transfer a packet when the S-modules S-Controller entered its XFER16 Slave Controller state. If a given S-module implements the MPR signal to control data ow from/to the M-module, the DOR bit is set after the S-modules S-Controller enters its XFER16 Slave Controller state while the S-module is asserting the MPR signal (11.4.1a). 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-modules M-Controller 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 <0>), when set, indicates to the M-module that the S-module detected a State Sequence Errorits S-Controller has made a transition to the ERROR Slave Controller state (7.1.1; gure 7-1; 11.6.1).
9-12
IEEE Std 1149.5-1995
Table 9-5Values of Bus Error register bits at power-up and after reset
PB 16 (msb) 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 (lsb) Key: RB 15 Mnm Values at power-up and after reset* 0 (if unused) User-dened (otherwise) 0 (if unused) User-dened (otherwise) 0 (if unused) User-dened (otherwise) 0 (if unused) User-dened (otherwise) 0 0 0 0 0 0 0 0 0 0 0 0
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BMR SDF CRU IPC IPS PTE CSE ILC PRE DOR SSE
*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 message that was supposed to cause reset.
9-13
IEEE Std 1149.5-1995
Table 9-6Summary of criteria for setting Bus Error Register Error bits
Applicable rules Bus Error register bit to be set Slave Controller state(s) in which S-Controller may reside when error-conditioncausing bit to be set will be detected PAUSE Any state, S, such that a packet bit is expected to be transmitted while the S-Controller is in SXFER16 through XFER0. PAUSE XFER16, EOM PAUSE PAUSE, XFER16 Packet type(s), awed reception or transmission of which may cause bit to be set
9.3.1a 11.7.1a
BMR SDF
HEADER ACKNOWLEDGE (except during a Contend for Bus sequence or in response to the Verify BMR command), DATA HEADER, PORT ID (17.1.1a) DATA PORT ID (17.1.1a) Data Transfer Port Errors may be caused by problems within the S-module rather than by a packet received by the S-module. HEADER, ACKNOWLEDGE, DATAin the case of an error such as that described in 11.8.1c. DATA (following and not including a PORT ID packet (17.1.1a))in the case of an error such as that described in 11.8.1b. HEADER HEADER ACKNOWLEDGE/PACKET COUNT, DATA ACKNOWLEDGE/PACKET COUNT, DATA ACKNOWLEDGE/PACKET COUNT, DATA
11.12.1a, 11.12.1b 11.11.1a, 11.11.1b 11.8.1a 11.8.1b, 11.8.1c
CRU IPC IPS PTE
11.9.1a, 11.9.1b 11.10.1a 11.5.1a, 11.5.1b 11.4.1a, 11.4.1b 11.6.1a, 11.6.1b
CSE ILC PRE DOR SSE
PAUSE PAUSE PAUSE XFER16 ERROR
NOTES 1Each error bit is set when the related error condition occurs. This table identies 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 numbers 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 manufacturers user documentation (11.1.1). 2The PORT ID packet is a DATA packet with a special use dened by 17.1.1a.
9-14
IEEE Std 1149.5-1995
9.4 Module Status register

9.4.1 Specications Rules (a) Bits of the Module Status register shall be identied as to whether they are inputs to the logical OR forming EVO (9.2.1h) or that forming BSE (9.2.1g). (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-modules 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.1d; 21.10.1f through 21.10.1h; 21.10.1n) for some such port, (i) an indicator for the occurrence of a trigger event shall be implemented as a bit in the Module Status register if not implemented as a user-dened bit in the Bus Error register (9.3.1g);
(ii) that Module Status register bit shall be an input to the logical OR driving EVO (9.2.1h). Recommendations (e) If a self-test completion indicator bit is not implemented in the Bus Error register of an S-module implementing self-test (9.3.1i), then the indicator for completion of an S-modules self-test (11.2.1; 18.1.1; 18.2.1; 18.4.1) should be (i) implemented as a bit in the Module Status register of that S-module;
(ii) designed to drive the logical OR feeding the EVO bit of the Slave Status register (9.2.1).
NOTETo know that a self-test has completed without detection of a failure, two indicators are requiredthe fact that the MFS bit of the Slave Status register has not been set is insufcient 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.
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.1h). 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 dened below. Data contained in Module Status register are used to clarify the Slave Status register EVO interrupt. The S-module manufacturers 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-modules Slave Status register (9.2.1h). Error bits will be cleared as dened for the Reset Slave Status command (16.3.1), the Reset Module
9-15
IEEE Std 1149.5-1995
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 identied 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-modules documentation (11.1.1).
9.5 Additional status registers

9.5.1 Specications Rules (a) The manufacturer of an S-module shall document any error bits contained within that S-modules additional status registers that drive the logical OR driving the EVO bit of the S-modules Slave Status register (9.2.1h). (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 register. (d) If the reading of an additional status register causes any of its bits to change state, this shall be described in the S-modules 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 dened in 16.1.1c. 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 ag recording that a given S-module has an active Disable Module I/O command (19.2.1);
(ii) A ag indicating that an S-modules 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 ag to record whether or not the trigger is set in the case of an IEEE Std 1149.1 Interface port having the Trigger on Event capability (21.10.1).
9-16
IEEE Std 1149.5-1995
9.5.2 Description A condition causing a bit in an S-modules additional status register to be set may cause the EVO bit of that S-modules Slave Status register to be set (9.2.1h; 9.2.1l). Complete documentation of additional status registers has to be provided. This documentation has to include register bit denitions, power-up values, set/ clear conditions, etc. If bits of an additional status register are used to record error conditions, manufacturers 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
9-18
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; gure 7-1; 11.6.1b) (which cause an S-modules SController to enter its ERROR Slave Controller state and immediately assert MSDessentially asserting an interrupt early to be sure that it will be asserted when the M-module is permitted to recognize 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-modules S-Controller 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 Smodules 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 specied in the present clause. Interrupts specied 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 Specications Rules (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 dened by table 10-1 and the supporting note and either the EVO or the BSE bit is set in that S-modules Slave Status register.
NOTES 1During a broadcast or multicast message, interrupts are allowed when an S-modules 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). 2The conditions described in 11.6.1b 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-modules Slave Status register) will signal an interrupt during its S-Controllers 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 PIE.
10-1
IEEE Std 1149.5-1995
IIE and PIE only affect interrupt generation by enabling or disabling S-module interrupts for specied Slave Controller states and do not affect pending interrupt status (i.e., EVO and BSE bits). The operation of IIE and PIE bits are as dened in table 10-1. Table 10-1Function of IIE and PIE bits in determining interrupt behavior of an S-module
Module uniquely addressed Pause Pause Pause/idle Pause/idle Module addressed via broadcast or multicast No interrupts allowed Pause Idle Pause/idle
IIE (table 9-1) 0 0 1 1
PIE (table 9-1) 0 1 0 1
Module not addressed No interrupts possible No interrupts possible Idle Pause/idle
NOTEThe entry pause in a cell of the above table indicates that, if a given S-modules Slave Status register has its IIE and PIE bits set as in the two left-most columns of the given cells 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-modules Slave Status register has its IIE and PIE bits set as in the two left-most columns of the given cells row, that S-module may source an interrupt when its S-Controller is in either its EOM or IDLE Slave Controller state.
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, the PIE bits having the value of logic 1 can be interpreted as permitting interrupts when the S-modules S-Controller is in its PAUSE Slave Controller state. However, in an S-module 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 interrupt is serviced. If an S-module with a pending interrupt loses a Contend 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 interrupt 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-modules S-Controller is in its XFER16 Slave Controller state. The subsequent 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
IEEE Std 1149.5-1995
MCLK MCTL MMD IDLE_00 HEADER BITS M-transfer states 1st M-PACKET BITS EOM_00 state state PAUSE_01 M-transfer states PAUSE_01 IDLE_00 EOM IDLE S-transfer states 2 clocks MSD Interrupts possible No interrupts possible Interrupts possible 1st S-PACKET BITS Interrupts possible only in response to a State Sequence Error (11.6.1b) Interrupts possible PAUSE S-transfer states PAUSE IDLE
Interrupt asserted
NOTEInterrupts are permitted to be multiplexed onto the MSD signal during times when the interrupting S-module has its S-Controller in its PAUSE, IDLE, or EOM Slave Controller state as shown in figure 10-1. The row marked M state provides data on current Master Controller state during the time represented in the figure. The row marked S state provides the same information with regard to Slave Controller states. Link layer controller state change and I/O relative timing follow the models of figures 6-2 and 7-3. Interrupts may be asserted on a rising edge of the MCLK signal during the periods indicated. Whether an interrupt will actually occur at any given time at which one is pending is determined according to setting of the IIE and PIE bits of the given S-modules Slave Status register (table 10-1 and accompanying note). In the example of figure 10-1, the M-module is being operated in a manner such that the uniquely addressed S-modules S-Controller remains in its PAUSE Slave Controller state for four cycles of the signal on MCLK after each packet transmission within a message. In addition, the IIE bit of the uniquely addressed S-modules Slave Status register has been set, permitting assertion of an interrupt as illustrated.
Figure 10-1S-module generated interrupt timing in relation to the signal on MCLK, Slave Controller states of an interrupting S-modules S-Controller, and MTM-Bus message transfer
10-3
IEEE Std 1149.5-1995
10-4
IEEE Std 1149.5-1995
11. S-module error response requirements

S-module error handling affects both MTM-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 by means of bits in an S-modules Bus Error and Slave Status registers. When an error bit is set within the S-modules Bus Error register, this causes the BSE bit of the Slave Status register to be set in the S-modules Slave Status register as required by 9.2.1g. Criteria for setting bits in the Bus Error register are indicated in table 9-6. Failure of an S-modules self-test will result in the MFS bit of that S-modules Slave Status register being set and the BSY bit of that register being cleared (11.2.1). In addition, it is recommended that a bit of the Module Status register be used to record the completion of an S-module self-test (9.4.1e). This combination of values for the MFS and BSY bits or some other S-module Status register bit with the same meaning causes the EVO bit of the Slave Status register to be set (9.2.1h(ii)). Once the BSE bit or the EVO bit of an S-modules Slave Status register is set, the S-module is required to indicate an interrupt to the M-module consistent with the specications in 10.1.1. A discussion of recovery after an error at the levels of both packet and message are discussed in 13.2.
11.1 S-module error responsegeneral requirements

11.1.1 Specications Rules (a) Any condition of an S-module fullling 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-modules manufacturers 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 1149.5-1995
(iii) means (if any) of operating the S-module via the MTM-Bus while the error is not remedied. (c) For each error type specied in clause 11 or by an S-module manufacturers 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-modules 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 1With regard to 11.1.1c(i) it is sufcient to indicate an edge of the MCLK signal since the following requirements 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 MMD_REG are presented to an S-modules S-Controller in the model of gure 7-3 as the time of detection of a State Sequence Error (11.6.1). 211.1.1c(ii) allows the designer of an MTM-Bus implementation to know what interrupts will occur while an S-modules S-Controller is in its PAUSE Slave 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, 11.1.1c(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 error-handling procedure shall take precedence over the dened message format of any currently executing command unless specied otherwise in the S-module manufacturers documentation. (f) If more than one error is detected by an S-module and the relevant set of error-handling requirements conict in terms of their effect on externally observable behavior of that S-module, then precedence with regard to nal impact on external behavior of that S-module shall be as follows: (i) Collision Error;
NOTEOnce 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;

NOTEBarring 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
IEEE Std 1149.5-1995
(iii) unless specied otherwise in the detecting S-modules manufacturers documentation, an errorhandling procedure requiring the transmission of NULL packets for the remainder of the current message;
NOTEBarring a requirement to hold the MSD signal at a constant logical value or S-module manufacturers specications to the contrary, the transmission of NULL packets has precedence over transmission of non-NULL DATA packets.
(iv) unless specied otherwise in the detecting S-modules manufacturers documentation, an errorhandling procedure requiring transmission of DATA packets with the data contained in them xed 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 exibility 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 11.1.1a. Moreover, if an S-module offers enough exibility 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.
11.2 S-module self-test failure response requirements

11.2.1 Specications Rules (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.
NOTEWhen 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.1h(ii); 9.4.1e). This Standard recommends (9.4.1e) that a Module Status register bit be used as an indicator of the S-modules self-test failure.
Permissions (b) Information concerning a self-test failure beyond that required by 11.1.1a may be recorded in a userdened bit of an S-module status register (9.3 through 9.5).
11-3
IEEE Std 1149.5-1995
11.2.2 Description When an S-module fails a self-test, diagnostic information may be available and be reected in some S-module status register as dened by an S-modules manufacturers documentation. To know if a self-test passed, two indicators are neededone for failure detection and one for self-test completion. This is treated in 18.1.1e 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.
11.3 Broadcast 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-modules 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, in 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 of a faulty HEADER packet does not cause the BMR bit to be cleared (table 9-4 and accompanying notes). Setting/clearing the BMR bit is independent of the contents of the S-module status registers. The BMR bit is only required to be valid at the conclusion of a broadcast or multicast message. During the receipt of a broadcast or multicast message or prior to the receipt of another, immediately following message by that S-module, the state of the BMR bit in the S-modules Bus Error Register can be affected only by the presence or absence of errors occurring during receipt of the HEADER packet of the given multicast message; the execution of the command received in the HEADER of the given multicast message if and only if such execution causes a reset of the S-module. If it is desired to check the success or failure of transmission of the HEADER packet of a particular broadcast or multicast message. The BMR bit should be cleared by a suitable command in the message just prior to the message of interest. If any S-module intended to be addressed by the message of interest fails to become addressed (possibly due to the detection of an error during transmission of the HEADER packet), the BMR bit in that S-modules Bus Error register will not be set. This fact can be ascertained by polling relevant S-modules or by use of the Verify BMR command (16.12.1). A broadcast or multicast message that results in clearing of an S-modules BMR bit may make determination of the success or failure of transmission of the HEADER packet of that message to that S-module impossible. The BMR bit in such an S-modules 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
IEEE Std 1149.5-1995
11.4 S-module Data Overrun Error and response requirements

11.4.1 Specications Rules (a) An S-module that is asserting the MPR signal, shall set the DOR bit in that S-modules Bus Error register upon the S-modules S-Controllers 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-modules Bus Error register upon the given S-modules S-Controllers entering its XFER16 Slave Controller state. (c) Any response to a Data Overrun Error beyond those described in 11.4.1a and 11.4.1b shall be as dened in the S-module manufacturers 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 (i) may continue to participate in that message after taking the actions required by 11.4.1a and 11.4.1b;
(ii) may cease to participate in any continuation of that message after taking the actions required by 11.4.1a and 11.4.1b and (subsequently) having its S-Controller enter its PAUSE Slave Controller state.
NOTEThe continuation of a message after occurrence of a Data Overrun Error might produce unpredictable results.
11.4.2 Description When the MPR signal is asserted, and the S-modules 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 transfer/receive data when its S-Controller enters its XFER16 Slave Controller 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 Specications Rules (a) An S-module that detects a Parity Error in an HEADER packet
11-5
IEEE Std 1149.5-1995
(i)
shall not set or clear any bit in that S-modules Bus Error register;
(ii) shall not become addressed.

NOTESince an S-module detecting a Parity Error in 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-modules 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-modules Bus Error register within one cycle of the MCLK signal following detection of the error.
NOTESee 11.1.1c for requirements on documentation of the time of detection of errors and the period (interrupt latency) between error detection and the detecting S-modules rst raising an interrupt.
(c) Subsequent to detection by a given S-module of an error described in 11.5.1b 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.
NOTEContinuation 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, 11.5.1b, and 11.5.1c shall be as dened in the S-module manufacturers documentation. 11.5.2 Description An HEADER packet having incorrect parity will not cause any error bits 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 being 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 S-module intended to be uniquely addressed will not transmit an ACKNOWLEDGE packet. Therefore, it is wise to 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 Parity Error has been detected in a packet other than an HEADER packet, the details of its operation in such circumstances have to be fully documented (22.1.1d).
11.6 S-module State Sequence Error response requirements

11.6.1 Specications Rules (a) An S-module that detects a State Sequence Error (7.1.1; gure 7-1) when not addressed (i) shall not become addressed;
(ii) shall not set or clear any bit in that S-modules Bus Error register;
11-6
IEEE Std 1149.5-1995
(iii) shall take no additional action in response to the detected State Sequence Error beyond that prescribed in 7.1.1 and gure 7-1.
NOTES 1The process of detecting a State Sequence Error involves the S-Controllers transition to its ERROR Slave Controller state (gure 7-1). 2Since 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-modules 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.
(b) A uniquely addressed S-module that detects a State Sequence Error (7.1.1; gure 7-1) during transmission of a packet (i) shall set the SSE bit in that S-modules Bus Error register upon that S-modules S-Controllers entry into its ERROR Slave Controller state (7.1, gure 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-modules S-Controller remains in its ERROR Slave Controller state; (iv) shall release the MSD signal on the rst rising edge of the MCLK signal after the given Smodules S-Controller enters its IDLE Slave Controller stateunless the specications of 10.1.1 require the MSD signal be asserted at that time.
NOTES 1The process of detecting a State Sequence Error involves the S-Controllers transition to its ERROR Slave Controller state (gure 7-1). 2A uniquely addressed S-module is required to assert the MSD signal upon the entry of that S-moduless SController into its ERROR Slave Controller state. When an S-Controller has entered its ERROR Slave Controller state, the S-module containing 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 to create an interrupt. If an S-module always asserts the MSD signal while in its S-Controllers ERROR Slave Controller state, the Mmodule can detect an interrupt at the earliest possible time. Once the S-modules S-Controller makes the transition 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-modules Slave Status register.
(c) When addressed by a broadcast or multicast message, an S-module that detects a State Sequence Error (7.1.1, gure 7-1) during transmission of a packet (i) shall set the SSE bit in that S-modules Bus Error register upon that S-modules S-Controllers entry into its ERROR Slave Controller state (7.1, gure 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-modules S-Controller remains in its ERROR Slave Controller state.
11-7
IEEE Std 1149.5-1995
NOTES 1The process of detecting a State Sequence Error involves the S-Controllers transition to its ERROR Slave Controller state (gure 7-1). 2 Once the S-modules S-Controller makes the transition 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-modules Slave Status register as dened in table 10-1. 3Behavior as to assertion or release of MSD when a State Sequence Error is detected during a broadcast or multicast message is consistent with the specication 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.1a). 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. 4When 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 1. This indicates the presence of an error because at least one bit of an S-modules 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.
11.6.2 Description An HEADER packet transmission during which a State Sequence Error is detected will not cause an S-module to set any error bits or cause an interrupt to be signaled, and an S-module detecting the State Sequence Error will not become addressed. This will prevent an excessive number of interrupts from being signaled due to single-bit errors on the MCTL signal. The M-module will detect HEADER errors by the lack of an expected S-module response. As noted in the case of Parity Errors (11.5.2), it is wise to set the Acknowledge Request bit in the HEADER packet of a message intended to be addressed to a single S-module. 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 will record the occurrence of the error so that an interrupt not serviced while the S-modules S-Controller is in its ERROR Slave Controller state can be signaled again at a later time if necessary.
11.7 MSD signal collision response requirements

11.7.1 Specications Rules (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.1a; 4.3.1b; gure 4-1) while the S-modules S-Controller is in one of its Stransfer 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 within 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 Smodules S-Controller is in a Slave Controller state in which an interrupt may be signaled
11-8
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 1MSD signal collision occurs when two S-modules both operate as though they were uniquely addressed. 2This 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. 3When the S-module is permitted to generate an interrupt it will be required to do so because of the SDF bits being set in the S-modules 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 reporting 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 Specications Rules (a) When an addressed S-module detects that an unsupported logical Port Identier (clause 21) was selected for a Data Transfer class command (clause 17), the S-module (i) shall set the IPS bit of its Bus Error register;
(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.1a) 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 DATA packet the next time the S-modules S-Controller is in its XFER16 Slave Controller state and
(ii) for any reason other than the occurrence of a Data Overrun Error (11.4.1), 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.1b or 11.8.1c and during the same message in which such detection took place, the default error response action for an Smodule shall include its continued participation in the current message.
11-9
IEEE Std 1149.5-1995
(e) When an addressed S-module detects that a port currently selected (17.1.1a) by a Data Transfer class message is inaccessible for any reason, the S-module shall set the PTE bit of the Bus Error register within one cycle of the MCLK signal of detecting the error. (f) 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. (g) 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 DATA packets required by the port-specic 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 11.8.1a, 11.8.1b, 11.8.1c, and 11.8.1d shall be as dened in the S-module manufacturers documentation. 11.8.2 Description The S-module will detect an Illegal Port Selected Error after receiving the PORT ID packet within a Data Transfer class message if the Port Identier contained in that packet is not supported. See table 21-1 for the list of reserved Port Identiers. Errors reported by a currently selected port or the inability to access data intended to be transmitted by the S-module are reasons for setting the PTE bit of an S-modules Bus Error register. While the default action for an S-module detecting an error of the type described in 11.8.1b and 11.8.1c is to continue transmitting DATA packets to the M-module, other responses (including the transmission of NULL packets instead of expected DATA packets) are permitted as long as they are fully documented by the S-modules manufacturer.
11.9 S-module Command Sequence Error response requirements

11.9.1 Specications Rules (a) When an S-module is addressed by an Enable Module Control (EMC) message (16.10.1) and does not receive a command requiring the EMC command in the rst HEADER packet following receipt of the EMC command (table 15-1) or is not addressed in the rst 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 1In case an S-module is addressed in a HEADER packet that causes a Command Sequence Error, the Smodule will execute the command the command code of which appears in the Command eld of that HEADER
11-10
IEEE Std 1149.5-1995
packet. This is required on the assumption that there may be a system critical reason for interrupting the expected command sequence. 2According to 16.10.1c, 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 dened in 11.9.1a and 11.9.1b and the Acknowledge Request bit was set in the most recently received HEADER packet, the detecting Smodule shall transmit an ACKNOWLEDGE packet as required (14.1.1b). (d) If a given S-module detects a Command Sequence Error as dened in 11.9.1a and 11.9.1b, then with the exception of an ACKNOWLEDGE packet transmitted under the conditions specied 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.1d, then the time-out causing the record of an EMC message to be deleted shall also cause the CSE bit of the S-modules Bus Error register to be set. 11.9.2 Description A Command Sequence Error will be detected while the detecting S-modules S-Controller is in its PAUSE Slave Controller state immediately following an HEADER packet transfer.
11.10 S-module Illegal Command Error response requirements

11.10.1 Specications Rules (a) 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), a Reserved 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. (b) If a given S-module detects an Illegal Command Error as dened in 11.10.1a and 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). (c) If a given S-module detects an Illegal Command Error as dened in 11.10.1a, then with the exception of an ACKNOWLEDGE packet transmitted under the conditions specied in 11.10.1b, the Smodule 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
11.10.2 Description An Illegal Command Error will be detected while the detecting S-modules S-Controller is in its PAUSE Slave Controller state following the transfer of the HEADER packet containing the command code in question. The Illegal command provides a method for the S-module to detect a stuck-at-one condition on the MTMBus (16.17.2). Detecting reserved and unimplemented command codes provides a method for testing validity of S-module command code interpretation.
11.11 S-module Packet Count Error response requirements

11.11.1 Specications (a) When an S-module that implements packet counting (14.2.1) detects a Packet Count Error (9.3.1; gure 9-4), then the S-module (i) shall set the IPC bit in its Bus Error register;
(ii) shall continue participation as dened in the S-module manufacturers documentation in any message that may still be current.
NOTEWhen unexpectedly few packets are transferred as part of a message following successful transmission of the PACKET COUNT packet of that message, the S-module can only determine this is the case after the completion of the message or by detection of a State Sequence Error. In either case, an S-module detecting the Packet Count Error will set the IPC bit in its Bus Error Register. In the last case, the SSE bit in the Bus Error register will also be set (11.6.1). A State Sequence Error occurring during transmission of the PACKET COUNT packet will result in only the SSE bits being set.
(b) An S-module shall set the IPC bit of the S-modules Bus Error register when the S-modules S-Controller enters its IDLE Slave Controller state following a message consisting only of transmission of a HEADER packet addressing the S-module and, in addition, either of the following occurs: (i) The S-module in question implements packet counting (14.2.1); and, in the given HEADER packet, the Acknowledge Request bit is set; and the command code of the Data Echo Test command (16.11.1) is not contained in the given HEADER packets Command eld.
(ii) In the given HEADER packet, the Command eld 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 transferred in a message is not equal to the number of packets specied 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-modules 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.
11-12
IEEE Std 1149.5-1995
11.12 S-module Command Resource Unavailable Error response requirements

11.12.1 Specications (a) 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. (b) 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-moduless 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 1The 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). 2Core class commands are always executed despite the state of the BSY bit.
(c) If a given S-module detects a Command Resource Unavailable Error as dened in 11.12.1a and 11.12.1b 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). (d) If a given S-module detects a Command Resource Unavailable Error as dened in 11.12.1a and 11.12.1b, then with the exception of an ACKNOWLEDGE packet transmitted under the conditions specied in 11.12.1c, 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 available at the time when the command was received. A specic 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 11.1.1.
11-13
IEEE Std 1149.5-1995
11-14
IEEE Std 1149.5-1995
12. MTM-Bus Message Layer: General requirements

12.1 MTM-Bus Message Layer general requirements
12.1.1 Specications Rules (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 eld of the HEADER packet (5.2.1) of that message.
NOTERequirements covering commands and their command codes are to be found in clauses 1520.
(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.1d; 5.3.1; 5.4.1; 13.1.1); (iii) zero or more DATA packet pairs (5.2.1d; 5.5.1; 5.6.1).
NOTES 1The term packet pair describes the two packets (one sent by the M-module and one by an S-module) satisfying the condition that the transmission of the last 15 bits of the M-module-originated packet are transmitted simultaneously with the rst 15 bits of the S-module originated packet. 2The operation of the M-module with regard to transmission of PACKET COUNT packets is covered in 13.1.1.
(d) MTM-Bus broadcast and multicast messages other than 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 transmission 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 DATA packets (5.5.1, 5.6.1).
NOTES 1Broadcast 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.1a). 2The 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.
NOTEIf 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 1149.5-1995
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-modules 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.
(f) 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-modules being forbidden to transmit data (8.2.1a; 12.1.1d)] shall occur without any alteration in action or effect.
NOTEIf 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.1a and 12.1.1d.
12.1.2 Description An MTM-Bus message consists of one or more 17-bit packets (clause 5) being transmitted between the Mmodule and one or more S-modules. The types of packets transmitted on the bus include HEADER packets, ACKNOWLEDGE packets, PACKET COUNT packets, NULL packets and non-NULL DATA packets. Figure 12-1 depicts the four allowable MTM-Bus message sequences. As depicted, each message begins with a HEADER packet being sent from the M-module to all S-modules. This HEADER packet identies the Smodule(s) to participate in the message (via an address eld) and an indication of the message type (via a command eld). The HEADER packet format is described in 5.2. An ACKNOWLEDGE packet can be requested from an addressed S-module by setting the Acknowledge Request bit in a HEADER packet (5.2). An ACKNOWLEDGE packet returned by an S-module will contain the address of that module and the contents of that modules Slave Status register. The ACKNOWLEDGE packet is intended to be a bus transfer acknowledgment, indicating that an S-module has received the immediately preceding HEADER packet without error and informing the M-module of which S-module is responding. The Slave Status data contained in an ACKNOWLEDGE packet does not reect changes to the addressed S-modules Slave Status register that will occur as a result of receipt of the HEADER packet in which the ACKNOWLEDGE packet was requested (5.3; 9.2). Note that the Acknowledge Request bit is extraneous in the cases of the Contend for Bus (16.4.1), Verify BMR (16.12.1), and Data Echo Test (16.11.1) commands. The Contend for Bus and Verify BMR commands produce a response from both uniquely addressed S-modules and those addressed by broadcast or multicast. For all other broadcast or multicast commands dened 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.1a). 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 ACKNOWLEDGE 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 identies 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 unspecied 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 eld 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
IEEE Std 1149.5-1995
Packets Sent by M-module
Packets Sent by S-module
HEADER NOTEMessages of types a and b are called simple messages. HEADER
b
PACKET COUNT ACKNOWLEDGE
HEADER
c
PACKET COUNT ACKNOWLEDGE
1st M-module DATA
1st S-module DATA
2nd M-module DATA
2nd S-module DATA
HEADER
d
1st M-module DATA 1st S-module DATA
2nd M-module DATA
2nd S-module DATA
NOTEMessages may consist of a single HEADER packet or include transfer of ACKNOWLEDGE/PACKET 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-1Packet transfers dening the MTM-Bus message sequences
12-3
IEEE Std 1149.5-1995
12-4
IEEE Std 1149.5-1995
13. MTM-Bus Message Layer: M-module requirements

13.1 M-module PACKET COUNT packet transmission requirements
13.1.1 Specications Rules (a) The M-module shall transmit a PACKET COUNT packet (5.4.1) as the rst packet following an HEADER PACKET (5.2.1) of which either of the following is true: (i) The Acknowledge Request bit (5.2.1d) 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 packets Command eld.
NOTEWhen 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 packets contents as compared to any other command.
(b) The M-module shall not transmit a PACKET COUNT packet (5.4.1) at any time other than those specied in 13.1.1a. (c) If an M-module is required to transmit a PACKET COUNT packet because 13.1.1a(ii) holds while 13.1.1a(i) does not hold, then the packet count transmitted shall be zero.
NOTEAny 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 send a PACKET COUNT packet to an addressed S-module if the S-module is expected to return an 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.1a apply, no Smodule 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 dened in this document. After an interrupt received during a message, the M-module or an application controlling the M-module rst has to determine whether to continue or to terminate the message. That decision may be inuenced by the following: Interrupt sourceIf 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
S-module. In such a case a decision is required 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 importanceIf 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 latencyThis is the length of time that passes between an interrupts being signaled by an S-module and the interrupts being serviced (i.e., error condition cleared in the interrupting S-module). If transfer of a long message is to continue after an interrupt is detected by the M-module, there may be a signicant amount of time before the interrupt 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 recoveryThe M-Module retransmits the message as initially transmitted. This could take a signicant amount of time if the message was a data transfer containing many packets. Packet recoveryThe M-module retransmits the message starting 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 last M-module originated packet that was transferred correctly.
13-2
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 Specications Rules (a) An S-module shall decode each HEADER packet (5.2.1) received without errorto determine if that S-module is addressed (3.3.1).
NOTENo 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.1d.
(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.11.1) appears in the given HEADER packets Command eld. (c) Once an S-module is uniquely addressed and after an ACKNOWLEDGE packet has been transmitted if requested, an uniquely addressed S-module shall transmit DATA packets or NULL packets required by the decoded command in the manner specied in the command denition.
NOTES 1The 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.1c; 12.1.1e). Command codes are dened in clauses 1520. 2As specied in 8.2.1a, 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 eld the command code of the command, C, and the BSY bit in that S-modules Slave Status register is clear, then the S-module shall execute C.
NOTEError handling in case the BSY bit is set when a HEADER packet is received is specied in 11.12.1b.
(e) An S-module shall execute Core class commands (15.1; clause 16) regardless of the state of the BSY bit within that S-modules Slave Status register.
NOTES 1Core class commands (table 15-1) are executed whether or not the BSY bit is set in an S-modules 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. 2An S-modules application logic may need to be aware of activity in that S-modules 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 Smodules Bus Error register shall occur prior to execution of the command;
14-1
IEEE Std 1149.5-1995
(ii) the command execution shall begin while an addressed S-modules S-Controller is in its EOM Slave Controller state and before any subsequent message transmission can begin.
NOTES 1As a consequence of this rule, those simple commands (12.1.1; gure 12-1) that cause a reset of an Smodules Bus Error register (9.3.1) will clear the BMR 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. 2The setting of the BMR bit (9.3.1; gure 9-4) by commands not covered by 14.1.1f is specied within the denition of such commands (where required) (22.1.1f). The time (period) of execution of commands not covered by 14.1.1f is required to be documented (22.1.1f) by an S-modules manufacturer.
14.1.2 Description If the Acknowledge Request bit is set in a HEADER packet, a uniquely addressed S-module responds with an ACKNOWLEDGE packet during the next packet transfer period as shown in gure 6-3. The 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 packet, a uniquely addressed S-module will transmit DATA packets as required by the command received in the HEADER packet (gure 15-1). S-module responses to MTM-Bus commands are described in clauses 1620.
MCLK
MCTL
MMD
M-module xmitted bits
M-module xmitted bits
MSD
S-module xmitted bits 2 clocks
S-module xmitted bits
NOTEFull-duplex transmission of DATA packets is supported on commands that require it as shown in these final packets of a data transfer message. Note the delay of two cycles of the MCLK signal between start of an M-module packet transmission and start of the linked S-module packet transmission.
Figure 14-1Full-duplex data transmission
14.2 S-module packet-counting requirements

14.2.1 Specications Rules (a) In order for any S-module to be said to implement packet counting (14.2.1b): (i) The manufacturer of the S-module shall document the S-module as implementing packet counting.
14-2
IEEE Std 1149.5-1995
(ii) The S-module shall extract the data from the Packet Count eld of each PACKET COUNT packet received. (iii) Subsequent to the required action of 14.2.1a(ii), the S-module shall treat the extracted 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 nonzero packet count, the S-module shall compare the number of packets received during that message following 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 packets of a message following a PACKET COUNT has exceeded the packet count of the message.
NOTEPacket Count Error handling is treated in 11.11.1.
(vii)The S-module shall recognize as a Packet Count Error the case in which a message terminates with the number of packets transmitted after the PACKET COUNT packet of the message less than the packet count of the message.
NOTEPacket Count Error handling is treated in 11.11.1.
(viii)The S-module shall behave as though it failed to satisfy the requirements dened in 14.2.1a(i) 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 packet counting (14.2.1a). 14.2.2 Description In cases in which the number of DATA packets to be transmitted by an M-module are known in advance, 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 Sequence Error 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. In these gures, the following types of errors can be distinguished: Header Errors Command Errors Data Packet Errors (Types 1 and 2) Data Overrun Errors Post-Message Errors
HEADER ErrorsHeader Errors are those that are detected when the S-module is expecting to receive a HEADER packet. Two potential errors may occur:
14-3
IEEE Std 1149.5-1995
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-modules 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.1a and 11.6.1a. When a Header Error is encountered, the S-module does not become addressed and, hence, will not transfer an ACKNOWLEDGE packet. Command ErrorsCommand Errors occur when a valid HEADER packet is received that causes a Command Sequence Error, Illegal Command Error, or Command Resource Unavailable Error. If requested in the HEADER packet, an ACKNOWLEDGE packet is returned despite the error conditions arising. The response to Command Errors is to wait for the S-modules 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 NULL packets for any packets requested beyond the ACKNOWLEDGE packet. Data Packet ErrorsData 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-modules S-Controller to enter its EOM Slave Controller state. These include State Sequence Errors, MSD Collision Errors, Illegal Port Selection Errors, and Command Resource Unavailable Errors as detailed in 11.6.1, 11.7.1, 11.8.1a, and 11.12.1. An MSD Collision Error causes an S-module to release the MSD signal. A State Sequence Error causes an uniquely addressed S-module to assert the MSD signal while the S-Controller of that S-module is in its ERROR Slave Controller state; a broadcast or multicast addressed Smodule will always release the MSD signal during the current message when a State Sequence Error occurs. An Illegal Port Selection Error or Command Resource Unavailable Error causes the S-module to return NULLS for any subsequent packet transfer. Type 2: Those in which the S-module may continue to respond depending upon the message. These include Port Transfer Errors and Parity Errors as detailed in 11.8.1b through 11.8.1d and 11.5.1. Data Overrun ErrorsData Overrun Errors occur when an S-modules S-Controller enters its XFER16 Slave Controller state while the S-module is not ready to transmit data. Response to a Data Overrun Error is detailed in 11.4.1. Post-Message ErrorsPost-Message Errors are those errors that occur after the message has been terminated (i.e., when all formerly addressed S-modules have their S-Controllers in their IDLE Slave Controller state). These errors include Incorrect Packet Count Errors and Port Transfer Errors. If the Acknowledge request bit was set in the HEADER packet of an addressed S-module and the bus enters EOM prior to the ACKNOWLEDGE packet transfer, the S-module will set the IPC bit indicating an incorrect packet count (11.11.1b; 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
IEEE Std 1149.5-1995
Slave Controller 7.1.1a, State figure 7-1 XFER16 IDLE
7.1.1d, 7.1.1e, 12.1.1c(i), HEADER packet. 12.1.1d(i) Receive first bit of
Wait for IDLE Slave Controller state. 11.6.1a, figure 7-1
Yes
figure 7-1 State Sequence Error? No
Wait for IDLE Slave Controller state. 11.5.1a, figure 7-1
Slave Controller state PAUSE XFERx figure 7-1
Wait for IDLE Slave Controller state. 3.3.1g, Figure 7-1 11.9.1a(ii) No
See note below.
No
EMC was previous cmd ? Yes Set Error bit. 11.9.1b
Yes
figure 7-1 11.5.1a Parity Error? No 3.3.1d, 11.6.1a, 11.5.1a
No
Addressed?
Yes Return NULL packets until S-Controller enters IDLE Slave Controller state. 11.9.1b, 11.12.1ab 12.1.1e No
11.9.1c, 11.10.1b, 11.12.1c Set Error bit. 11.9.1a, 11.10.1a, 11.12.1ab Yes
Yes
Acknowledge Request bit set? Yes
Command Error? No
NOTEThis diamond should contain the following text: Command Sequence Error & EMC was previous command?
NOTEMessages begin with a HEADER packet. Header Errors (setting PRE or SSE) are treated as though the S-module were not addressed. If no Header Error occurs, the S-module uses the contents of the HEADER packet to determine if that S-module is addressed. If an S-module determines that it is addressed, Command errors (setting CSE or ILC) are captured if such occurred; and the message sequence continues through completion of an ACKNOWLEDGE packet transfer (via connector A), if the Acknowledge Request bit was set in the HEADER packet.
Figure 14-2MTM-Bus message sequencepart 1
14-5
IEEE Std 1149.5-1995
B
[Release MPR signal 8.3.1a]
Yes
A G
Slave Controller state PAUSE Ready to xmit/rcv? [Assert MPR signal 8.3.1a]
No
IDLE
XFER16
14.2.1a(vi)-(vii) Set IPC bit. 11.11.1a

Yes NOTEIf DATA packets are to be returned after an error, then the packets have to have good parity.
Yes
Packet Count Error? No
No
Post Message Errors? Yes
Continue Msg.? See Docs. No
Set Error bit. 11.11.1a, 11.8.1b
Documented response
Set DOR bit. 11.4.1a-b
No
Ready to xmit/rcv? Yes Begin packet transfer.
NOTES 1SSE = State Sequence Error 2Coll. = MSD Collision Error 3Bracketed operations related to the MPR signal only apply if the latter is implemented.
Release MSD during packet xfer til EOM.11.7.1a
4.3.1a Set SDF bit. 11.7.1a
Packet Error? Coll. SSE None
Assert MSD signal until EOM. 11.6.1b
Set SSE bit. 11.6.1b
7.1.1a, Fig. 7-1
Slave Controller state PAUSE XFERx
NOTEAssertion or release of MPR (8.3.1) may occur in any S-transfer state. Decision is analogous to that in dotted box G, above.
NOTEAn S-module asserts MPR until it is ready to transmit/receive 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.
14-6
Fig. 7-1, 7.1.1a
IEEE Std 1149.5-1995
Replace data by NULL until IDLE. 11.8.1a
Yes
Command Error? No
NOTEThe subsequent transmission of NULL packets may be interrupted by detection of a Collision Error or a State Sequence Error.
Replace data by NULL until EOM. 11.8.1a
Set Error bit. 11.8.1a
Yes
Illegal port selected? No
Set Error bit. 11.8.1b 11.5.1b
Yes
Type 2 Packet Error? No
14-7
IEEE Std 1149.5-1995
14-8
IEEE Std 1149.5-1995
15. MTM-Bus Message Layer: Commandsgeneral requirements

15.1 MTM-Bus commandsgeneral requirements on command codes and command classes
The seven-bit command eld within a HEADER packet is interpreted by an S-module following the command code denitions in gure 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 I/O Control and Test class, the Standard-Extension class, and the User-Dened 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 unimplemented command) is contained in the HEADER packet of some message, it will be construed as an error (11.10.1). 15.1.1 Specications Rules (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 dened in table 15-1.
NOTEThese commands are conveyed to S-modules in the seven-bit Command eld of a HEADER packet (5.2).
(b) User-Dened commands shall correspond only to seven-bit codes belonging to the User-Dened class. (c) Commands dened 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 those 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.
NOTEFailure to transmit an Enable Module Control message immediately before a message containing 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 command 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 Command 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 1149.5-1995
Permissions (g) Standard-Extension and User-Dened commands may be implemented (clause 20). 15.1.2 Description The seven-bit Command eld within a HEADER packet is used to dene the command to be executed by currently addressed S-modules. The basic command classes are described in table 15-1. Table 15-1MTM-Bus command codes
Command class Core Command codes 0000000 0000001 0000010 0000011 00001XX 0001000 0001001 0001010 0001011 0001100 0001101 0001110 0001111 0010000 0010001 00100100011111 1111111 0100000 0100001 0100010 0100010100111 0101000 0101001 0101010 01010110101111 0110000 0110001 0110010 0110011 0110100 0110101 0110110 01101111001111 10100001011111 Command Status Required Required Required Required Required Required Required Required Required Required Required Required Required Required Required Reserved Required Recommended Recommended Recommended Reserved Recommended Recommended Recommended Reserved Recommended Recommended Recommended Recommended Recommended Recommended Recommended Reserved Reserved
Read Status Abort a Reset Slave Status a Contend for Bus Multicast Group Select Enable Idle Interrupts Enable Pause Interrupts Disable Idle Interrupts Disable Pause Interrupts Enable Module Control Data Echo Test Verify BMR Initialize Application a Disable Module Control a Start Reserved Illegal Command Data Transfer Read Data Write Data Read/Write Data Reserved Module Initialization and Self-Test Reset Module with SBIT a (MIST) Reset Module without SBIT a Module IBIT a Reserved Module I/O Control and Test Disable Module I/O a (MICT) Enable Module I/O a Force Module Outputs a Sample ModuleNo Change a Sample ModuleDont Care a Sample Module with Force a Release Module I/O Reserved Standard-Extension Reserved for the use of standardsmaking bodies User-Dened 11000001111110 User-Dened commands Reserved aIndicates that an Enable Module Control (EMC) message has to precede a message conveying this command (15.1.1e).
15-2
IEEE Std 1149.5-1995
Core class commandsAll 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 implementation of these commands can be considered to be a virtual part of the MTM-Bus interface logic of an Smodule. 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.1e), requiring two potentially concurrently executing 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 I/O Control and Test class, the Force Module I/O and the commands causing sampling (most likely to have execution continuing signicantly after termination of a message, but not by very many cycles of the MCLK signal). In the Standard Extension and User classes, completely open, requiring careful checking by developers and users of S-modules. Whether one of the following listed commands can possibly be aborted is application-dependent: Data Transfer class commandsIt is recommended that S-modules implement Data Transfer class commands (14.1.1f) 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, onmodule buses, etc. Module Initialization and Self-Test (MIST) class commandsThis set of recommended commands instruct addressed S-modules to perform Built-In Self-Test routines, or to perform resetting (9.2.1b; 9.3.1b; 9.4.1b; 9.5.1b) 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 I/O Control and Test class commandsThis set of commands supports control and test of interconnections between modules. Although this testing may be implemented using techniques such as IEEE Std 1149.1 boundary-scan, these commands are generalized to allow any number of structural implementations.Three possible approaches are suggested for sampling S-module inputs. One or all of the corresponding messages should be implemented. Standard-Extension class commandsThe 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-Dened class commandsThese commands are those developed by bus interface designers or module developers to meet the requirements of their specic applications. These commands may be implemented to execute in hardware, rmware, or software. Table 18-1 relates the functions of Core class, MIST class, and MICT class commands useful in initialization, 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 1149.5-1995
15.2 Commands execution of which may be terminated upon receipt of another command
15.2.1 Specications Rules (a) For every implemented MTM-Bus command, C, that is liable to termination caused by receipt of a message transmitting another MTM-Bus command, the manufacturer of an S-module shall document each of the following and relate these items to the commands that may cause the termination: (i) the point(s) or period(s) during execution of C when the termination may occur;
(ii) the consequences of such termination(s) or the fact that the consequences are unpredictable; (iii) any indicators accessible after termination of execution of C that would be of diagnostic value to the S-modules user; (iv) the maximum number of cycles of the signal on MCLK that may occur between the time that the S-moduless S-Controller enters its EOM Slave Controller state at the termination of an MTM-Bus message transmission causing termination of execution of C and the time that all requirements of 16.2.1b are satised; (v) the impact (if any) of the termination of execution of C on all status registers (clause 9) that may be implemented in that S-module.
NOTES 1In some cases, interruption of a command might occur at any point in its operation; a statement to this effect would satisfy 16.2.1c. 2In case there is one point or a contained number of alternative points in a commands function at which a graceful termination is allowed, these have to be described by the manufacturer along with (for each such possible case) any indicators that can be of diagnostic value to the S-modules user.
15.2.2 Discussion A number of commands are not coterminous with the messages transmitting them. It is possible that a subsequent message (e.g., a Core class message) might be received by an S-module still executing a command. The requirements of 15.2.1 are intended to provide an S-module user with as much information about such conditions as is practicable.
15-4
IEEE Std 1149.5-1995
16. MTM-Bus Message Layer: Core class commands (00000000011111; 1111111)

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.1e; 15.1.2). These commands are dened in the present clause. The Core class commands provide the most basic interface to an S-modules MTM-Bus interface and also provide means of aborting activity of S-module applications. Access to status registers (including identication 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 command (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 Status 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 commands: 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 command (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 dening message formats and S-module responses to singlecast messages including these commands. 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 (8.2.1a; 12.1.1d).
16.1 The Read Status command (0000000)

16.1.1 Specications Rules (a) The message format of a Read Status message shall be as depicted in gure 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-modules Slave Status register, that S-module (i) shall respond to any additional packet transfers within the message by returning NULL packets;
16-1
IEEE Std 1149.5-1995
(ii) shall not clear the contents of the Bus Error register, Module Status 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-modules Slave Status register, that S-module shall respond in any subsequent packet pair transfers within the message by rst sending the contents of the Bus Error register, then the contents of the Module Status register, and then any number of packets with user-dened status in an order documented by the S-modules manufacturer. (e) If, in a Read Status message, both (i) an S-modules S-Controller enters its XFER16 Slave Controller state
(ii) the contents of all of that S-modules 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. (f) During a Read Status message, following the transfer by the addressed 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 dened by module documentation to be cleared by the Read Status command shall be, or shall have been, cleared.
NOTEClearing 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.1.1d).
(g) During a Read Status message, following the transfer by the addressed S-module of a DATA packet containing the Module Status register contents, those bits identied as Error bits in the Module Status register shall be, or shall have been, cleared.
NOTEClearing the error bits of the Module Status register may result in the EVO bit of the Slave Status register 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).
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 gure 16-1. An uniquely addressed Smodule 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 reect status that has changed as a result of the HEADER packet (5.3.1c). If the M-module does not terminate the message 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-dened status.
16-2
IEEE Std 1149.5-1995
M-MODULE
S-MODULE
HEADER This packet pair transfer 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 manufacturers documentation.
PACKET COUNT
ACKNOWLEDGE
NULL
Bus Error
NULL
Module Status
NULL
User-dened (1)
NULL
User-dened (n)
NOTEWhen a Read Status 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 Read Status message will take place (12.1.1f); and status registers will be cleared as in a singlecast message.
Figure 16-1Singlecast 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.1a; 9.3.1b; table 9.4), and will be set in all addressed S-modules at the conclusion of a successful execution of a broadcast/multicast Read Status 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-modules 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-modules 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-modules Bus Error register (11.1.1c; 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 specied in figure 6-1 is followed (i.e., PAUSE_01; EOM_00; IDLE_00). A Packet 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 Status 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 register contents (i.e., bits are not cleared following packet transfers).
16-3
IEEE Std 1149.5-1995
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 bitsif using a Reset Slave Status message is less desirable. A Read Status message is not a critical control message.
16.2 Abort command (0000001)

16.2.1 Specications Rules (a) The message format of an Abort message shall be as depicted in gure 16-2. (b) Upon receipt of an Abort message that has been immediately preceded by an EMC message, an Smodule 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-modules Slave Status register to be set;
(ii) shall wait in a safe mode dened by the S-modules manufacturers documentation.
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2After terminating command execution as required by 16.2.1b(i), the BSY bit in an addressed S-modules Slave Status register will be cleared because no MTM-Bus command will be executing (9.2.1).
(c) The maximum time that an S-module may take to complete the action specied in 16.2.1b(i) and achieve the safe mode of 16.2.1b(ii) shall be documented by the S-modules manufacturer. (d) If the S-module actions required to meet the requirements of this command take sufcient 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 (11.12).
NOTEThe 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 wont 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 stability or system function. In such a case the function of that module initiated by MTM-Bus commands can be rapidly stopped. Even if determination of counter measures may take some time, the problem module will be quiescent while such measures are being evaluated.
16-4
IEEE Std 1149.5-1995
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
This packet pair transfer is optional (may occur).
NOTEWhen an Abort message is broadcast or multicast, no S-module transmits anything (12.1.1d).
Figure 16-2Singlecast message format for an Abort message
16.3 Reset Slave Status command (0000010)

16.3.1 Specications Rules (a) The message format for a Reset Slave Status message shall be as depicted in gure 16-3. (b) Upon receipt of a Reset Slave Status message immediately preceded by an EMC message, an Smodule addressed by both messages shall terminate execution of any previously loaded MTM-Bus command.
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2After terminating command execution as required by 16.3.1b and completion of the actions required by 16.3.1c, the BSY bit in an addressed S-modules 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.1b; 9.3.1b; 9.4.1b; 9.5.1b) sufciently rapidly so that the action shall be completed before transmission of a subsequent message can begin.
NOTEReset condition of Slave Status and Bus Error registers are xed 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
16-5
IEEE Std 1149.5-1995
Reset Slave Status message does not reect the reset operation performed upon execution of the present command.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen a Reset Slave Status 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 Reset Slave Status message will take place (12.1.1f), and the addressed S-modules status registers will be reset.
Figure 16-3Singlecast message format for a Reset Slave Status message
16.4 Contend for Bus command (0000011)

16.4.1 Specications Rules (a) The message format of a Contend for Bus message shall be as depicted in gure 16-4. (b) Upon receipt of a Contend for Bus command, any addressed S-module that has the IIE bit or PIE bit set in that S-modules Slave Status register (9.3; clause 10; table 10-1), and has an interrupt pending (i.e., has BSE or EVO bit set in the Slave Status register), shall participate in a Contend for Bus sequence (16.4.1d). (c) Upon receipt of a Contend for Bus command, any addressed S-modules not meeting the conditions of 16.4.1b shall release MSD and behave as though not addressed for the remainder of the Contend for Bus message. (d) Participation in a Contend for Bus sequence shall mean that an S-module satisfying the conditions of 16.4.1b shall transmit an ACKNOWLEDGE packet (as constrained by 16.4.1e) according to the message format of gure 16-4 regardless of the state of the Acknowledge Request bit in the HEADER packet of the current message.
NOTEThe 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.1d, 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
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 register bit except as a consequence of 16.4.1g through 16.4.1j.
NOTEUnder 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.1d; 3.3.1f).
(g) If permission 16.4.1j 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-modules S-Controller enters its XFER16 Slave Controller state and
(ii) the contents of all of that S-modules 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.1j 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 dened by module documentation to be cleared by the Read Status (16.1.1) command shall be, or shall have been, cleared.
(i) If permission 16.4.1j 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 DATA packet containing the Module Status register contents or the contents of an user-dened status register, those bits in the Module Status (user-dened status) register that are dened by module documentation to be cleared by the Read Status command (16.1.1) shall be, or shall have been, cleared.
NOTEClearing the error bits of the Module Status register may result in the EVO bit of the Slave Status register 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 (j) Upon winning a Contend for Bus sequence, an S-module may respond to additional packet pair transfers by providing the contents of that S-modules Bus Error register, its Module Status register, and any user-dened 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 Contend 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 register are both cleared (table 10-1).
16-7
IEEE Std 1149.5-1995
M-MODULE
S-MODULE
HEADER Contending S-modules attempt to transmit ACKNOWLEDGE packet.
PACKET COUNT
ACKNOWLEDGE
NULL
Bus Error
NULL
Module Status
NULL
User-dened (1)
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 manufacturers documentation.
NULL
User-dened (n )
Figure 16-4Message format for a Contend for Bus message
An S-module wins a Contend for Bus sequence by successfully transmitting its ACKNOWLEDGE 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.1a; gure 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 Contend 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-module should never detect a collision when it is sourcing a logic 1 on the MSD signal. MTM-Bus packets are transmitted msb rst and that the most-signicant 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 ACKNOWLEDGE packets, each S-modules collision detection circuitry provides a means of comparison of that S-modules address and the value on MSD. When an S-module has a lower module address than some other participating Smodule, 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<16> of its ACKNOWLEDGE packet is transmitted. S-module B would drop out following the falling edge of the MCLK signal after bit<13> of its ACKNOWLEDGE packet is transmitted (gure 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 Contend 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
IEEE Std 1149.5-1995
MCLK
MCTL
MMD
HEADER
PACKET COUNT
MSD
ACKNOWLEDGE Enlarged section
MCLK MCTL 2 clocks
S-module 1 continues to transmit an ACKNOWLEDGE packet after the collision.

MSD S-module A MSD S-module B BIT 16 BIT 15 BIT 14 BIT 13 BIT 12
BIT 16
BIT 15
BIT 14
BIT 13
MSD remains released to end of message except for permitted interrupts.
Collision occurs.
NOTEIn the example of figure 16-5, two S-modules are participating in a Contend for Bus sequence. Both S-modules transmit the same value for each of the first three bits of the ACKNOWLEDGE packet. However, when bit<13> of the packet is transmitted, S-module 2 attempts to transmit a logic 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 desired behaviorthat 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-5Contend for Bus operations are used to identify which S-module sourced an interrupt
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.1i 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 transmitted, 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) (00001000000111) 16.5.1 Specications

Rules (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
(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)MS0 and MS1equal to bits<3..2> of the HEADER packet of that message.
NOTEBits<3..2> of an HEADER packet correspond to the two lowest order bits of that packets Command eld (5.2.1; gure 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 reect changes to the multicast select bits due to the received Multicast Select n command.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen a Multicast Select n 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 Multicast Select n message will take place (12.1.1f).
Figure 16-6Singlecast message format for a Multicast Select n message
Table 16-1Effect of Multicast Select n commands

Command code 0000100 0000101 0000110 0000111
Effect of command
Assign S-module to multicast group 0 Assign S-module to multicast group 1 Assign S-module to multicast group 2 Assign S-module to multicast group 3
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 signicant bits of the command code equal the new values for the MS0 and MS1 bits of an addressed S-modules Slave Status register.
16-10
IEEE Std 1149.5-1995
16.6 Enable Idle Interrupts command (0001000)

16.6.1 Specications Rules (a) The message format for an Enable Idle Interrupts message shall be as depicted in gure 16-7. (b) Upon receipt of an Enable Idle Interrupts message, an addressed S-module shall set the Idle Interrupts 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 ACKNOWLEDGE packet is requested in a singlecast Enable Idle Interrupts message, the contents of that packet will not reect the setting of the IIE bit (5.3.1c; 9.2; 10.1; table 10-1).
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen an Enable Idle Interrupts 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 Enable Idle Interrupts message will take place (12.1.1f).
Figure 16-7Singlecast message format for an Enable Idle Interrupts message
16.7 Enable Pause Interrupts command (0001001)

16.7.1 Specications Rules (a) The message format for an Enable Pause Interrupts message shall be as depicted in gure 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 ACKNOWLEDGE packet is requested in a singlecast Enable Pause Interrupts message, the data in that packet will not reect the setting of the PIE bit (5.3.1c; 9.2; 10.1; table 10-1).
16-11
IEEE Std 1149.5-1995
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen an Enable Pause Interrupts 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 Enable Pause Interrupts message will take place (12.1.1f).
Figure 16-8Singlecast message format for an Enable Pause Interrupts Message
16.8 Disable Idle Interrupts command (0001010)

16.8.1 Specications Rules (a) The message format for an Disable Idle Interrupts message shall be as depicted in gure 16-9. (b) Upon receipt of a Disable Idle Interrupts message, an addressed S-module shall clear the Idle Interrupts Enabled (IIE) bit in its Slave Status register. 16.8.2 Description The message format for the Disable Idle Interrupts command is shown in figure 16-9. If an ACKNOWLEDGE packet is requested in a singlecast message, the data in that packet will not reect the clearing of the IIE bit (5.3.1c; 9.2; 10.1; table 10-1).
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen a Disable Idle Interrupts 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 Disable Idle Interrupts message will take place (12.1.1f).
Figure 16-9Singlecast message format for a Disable Idle Interrupts message
16-12
IEEE Std 1149.5-1995
16.9 Disable Pause Interrupts command (0001011)

16.9.1 Specications Rules (a) A Disable Pause Interrupts message shall have the format depicted in gure 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 ACKNOWLEDGE packet is requested in a singlecast Disable Pause Interrupts message, the data in that packet contents will not reect the clearing of the PIE bit (5.3.1c; 9.2; 10.1; table 10-1).
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen a Disable Pause Interrupts 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 Disable Pause Interrupts message will take place (12.1.1f).
Figure 16-10Singlecast message format for a Disable Pause Interrupts message
16.10 Enable Module Control (EMC) command (0001100)

16.10.1 Specications Rules (a) The message format for an EMC message shall be as depicted in figure 16-11. (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;
NOTEThe 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
IEEE Std 1149.5-1995
(ii) upon detection of a faulty HEADER packet (i.e., detection of a Parity Error or State Sequence Error).
NOTENevertheless, error handling for Command Sequence Errors will be activated because no Smodule can become addressed upon receipt of a faulty HEADER packet (11.5.1a; 11.6.1a). Failure to be addressed in a message following an EMC message will trigger the Command Sequence Error response (11.9.1a).
Permissions (d) An S-module may be designed to delete its record of having received an EMC message after a documented number of cycles of the MCLK signal.
NOTE11.9.1e requires that, in an S-module implementing 16.10.1d, the action of deleting a record of having received an EMC message pursuant to a time-out as described in 16.10.1d 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-11. The EMC command can be thought of as a command that unlocks a mechanism preventing inadvertent execution of commands that have signicant impact on the operation of an addressed S-module or the system in which it resides. The EMC command allows a receiving module to execute a critical control function that may affect the state or operation of the modules application circuitry. An EMC message has to precede any message conveying a command marked by an asterisk (*) in table 15-1. These commands are called critical control commands. If a critical control command is received by an S-module in a message not immediately preceded by an EMC message, then that S-modules will not execute the critical control command, and the Command Sequence Error (CSE) bit of the Bus Error register will be set (11.9.1b). Likewise, if an S-module receives an EMC message that is not followed by a message conveying a critical control command, a Command Sequence Error is recorded (11.9.1a). Actions in response to Command Sequence Errors are treated in 11.9.1.
M-MODULE S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen an EMC message is broadcast or multicast, no S-module transmits anything (12.1.1d). However, normal Smodule processing that would be initiated by a singlecast EMC message will take place (12.1.1f).
Figure 16-11Singlecast 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
16.11 Data Echo Test command (0001101)

16.11.1 Specications Rules (a) The message format for a Data Echo Test singlecast message shall be as depicted in figure 16-12.
NOTEPacket 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-modulebeginning with the HEADER packet (gure 16-12).
NOTEDespite 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).
(c) 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).
NOTEThis is consistent with error handling for Parity Errors (11.5.1).
16.11.2 Description The message format for the Data Echo Test message is dened in figure 16-12.
M-MODULE
S-MODULE
HEADER
No ACKNOWLEDGE packet/PACKET COUNT packet pair can be transmitted regardless of the state of the Acknowledge Request bit in the HEADER packet (14.1.1b). At least one DATA packet shall be transmitted by the M-module.
DATA (1)
HEADER echo
DATA (2)
DATA (1) echo
Packet pair transfers depicted below this line are optional (may occur).
DATA (n)
DATA (n1) echo
NOTEWhen 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.1f).
Figure 16-12Singlecast 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
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 packeteven 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 arbitrary 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.12.1 Specications Rules (a) The message format for the Verify BMR Command shall be as illustrated in gure 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 shall release MSD for the remainder of the current message. (c) In response to receipt of the Verify BMR command, an S-module with the BMR bit in its Bus Error register (9.3.1) cleared shall transmit an ACKNOWLEDGE packet (gure 16-13), regardless of the state of the Acknowledge Request bit in the HEADER packet.
NOTEThe Verify BMR 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).
(d) If an S-module detects a collision on MSD while returning the ACKNOWLEDGE packet required by 16.12.1c and gure 16-13, that S-module shall immediately release the MSD signal prior to transmission 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 collision during the transmission of the ACKNOWLEDGE packet required by 16.12.1c and gure 16-13 shall set the BMR bit in that S-modules Bus Error register (9.3.1) and shall not clear any bits in the S-modules Slave Status register (9.2.1) except as a consequence of 16.12.1f through 16.12.1i. (f) If permission 16.12.1i is implemented in a given S-module and that S-module satises the conditions of 16.12.1e in a given Verify BMR message, then, if in that same message (i) that S-modules S-Controller enters its XFER16 Slave Controller state and
(ii) the contents of all of that S-modules 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.1i is implemented in a given S-module and that S-module satises the conditions of 16.12.1e 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
IEEE Std 1149.5-1995
<12..15> in the Bus Error register that are dened by module documentation to be cleared by the Read Status command (16.1.1) shall be, or shall have been, cleared.
(h) If permission 16.12.1i is implemented in a given S-module and that S-module satises the conditions of 16.12.1e 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 dened by module documentation to be cleared by the Read Status command (16.1.1) shall be, or shall have been, cleared.
NOTEClearing the error bits of the Module Status register may result in the EVO bit of the Slave Status register 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.1e 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 Smodules Bus Error register, its Module Status register, and any user-dened status in the order determined 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) commandthey 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 bitsif using a Reset Slave Status message is less desirable.
16-17
IEEE Std 1149.5-1995
M-MODULE
S-MODULE
HEADER Addressed S-modules with BMR clear attempt to transmit ACKNOWLEDGE packet.
PACKET COUNT
ACKNOWLEDGE
NULL
Bus Error
NULL
Module Status
NULL
User-dened (1)
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 manufacturers documentation.
NULL
User-dened (n)
Figure 16-13Message format for a Verify BMR message
16.13 The Initialize Application command (0001111)

16.13.1 Specications Rules (a) The format of an Initialize Application message shall be as dened in gure 16-14. (b) Upon its S-Controllers entering the EOM Slave Controller state at the termination of an of an Initialize 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 received MTM-Bus command that would otherwise cause the BSY bit of the S-modules Slave Status register to be set;
NOTEAs a result of 16.13.1b(i), the BSY bit of such an S-modules Slave Status register will be cleared once the Initialize Application command has been executed.
(ii) shall be initialized to a specic, manufacturer-documented state.

NOTEError handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b.
(c) The maximum time that an S-module may take to complete the actions described in 16.13.1b shall be documented by the S-modules supplier. (d) If the S-module actions required to meet the requirements of this command take sufcient 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 (11.12).
16-18
IEEE Std 1149.5-1995
NOTEThe 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.1b, 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. Module initialization sequences are based upon each S-modules 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 modules start-up code. S-modules without processors might be initialized by causing an Smodule reset (9.2.1b, 9.3.1b, 9.4.1b, 9.5.1b) to occur. Execution of this command includes aborting any currently executing MTM-Bus command (e.g., a self-test sequence), forcing S-module application circuitry to a known initial state as dened by the modules documentation, beginning module functional operation.
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen an Initialize Application 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 Initialize Application message will take place (12.1.1f).
Figure 16-14Singlecast message format for an Initialize Application message
The message format for the Initialize Application command is shown in figure 16-14. The Initialize Application command has to be proceeded immediately by an EMC command since the Initialize Application command will affect the operation and state of the module. The ACKNOWLEDGE packet (if requested in the HEADER packet) does not reect the results of the Initialize Application command execution. The module is initialized following the optional transfer of the ACKNOWLEDGE packet.
16.14 Disable Module Control command (0010000)

16.14.1 Specications Rules (a) The message format for the Disable Module Control Command shall be as illustrated in gure 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.1b) of the receipt of an EMC message.
NOTEThis 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
16.14.2 Description The message format for a Disable Module Control message is depicted in gure 16-15. It is necessary for the Disable Module Control command to be a critical control command so that no Command Sequence Error will occur when the attempt is being made to disable the mechanism that would cause such an error.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen a Disable Module Control 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 Disable Module Control message will take place (12.1.1f).
Figure 16-15Singlecast message format for a Disable Module Control message
16.15 Start command (0010001)

16.15.1 Specications Rules (a) The message format for the Start Command shall be as depicted in gure 16-16. (b) Upon its S-Controllers entering the EOM Slave Controller state at the termination of a Start message that has been immediately preceded by an EMC message, an S-module addressed by both these messages shall insure that S-module is in full functional operation.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEWhen a Start message is broadcast or multicast, no S-module transmits anything (12.1.1d). However, normal Smodule processing that would be initiated by a singlecast Start message will take place (12.1.1f).
Figure 16-16Singlecast message format for the Start command
16-20
IEEE Std 1149.5-1995
16.15.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 command is staticthe application is halted. The Start command provides the capability of leaving this state.
16.16 Reserved commands (00100100011111)

16.16.1 Specications Rules (a) An S-module shall respond to any of the Core class reserved commands in the same manner as is specied for the Illegal Command (16.17.1). 16.16.2 Description The reserved commands are reserved for future revisions of the MTM-Bus. They are not to be dened by the user. The command decodes for user-dened commands are identied and specied in table 15-1 and clause 20.
16.17 Illegal command (1111111)

16.17.1 Specications Rules (a) If an S-module receives a message containing in the command code eld of its HEADER packet the command code of the Illegal command, no action shall be taken other than those specied in clause 9 and in 11.10.1. 16.17.2 Description The Illegal command is dened 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-modules parity checking logic. An all-ones word would result in a module address of FF HEX, a command eld of 1111111 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 in 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 (11.10.1), giving rise to an interrupt if it is permitted to do so by its current programming. Note that if an ACKNOWLEDGE packet is requested, it will not reect the setting of the BSE bit due to the setting of the ILC bit in the Bus Error register (5.3.1c).
16-21
IEEE Std 1149.5-1995
16-22
IEEE Std 1149.5-1995
17. MTM-Bus Message Layer: Data Transfer class commands (01000000100111)

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 specied to allow as much exibility as possible.
17.1 General format requirements for Data Transfer class commands

17.1.1 Specications Rules (a) Each Data Transfer class message shall identify the port selected by that message by means of a Port Identier (PORT ID) packet (gure 17-1) that shall be transmitted from the M-module to the addressed S-module(s) (i) as the rst packet transferred following the transfer of the HEADER packet if no PACKET COUNT packet is transferred in the given message;
(ii) as the rst packet transferred following the transfer of the PACKET COUNT packet otherwise. (b) A Port Identier shall be a 16-bit binary number. (c) Following transmission of the PORT ID packet (17.1.1a), any addressing within the selected port or programming of a function receiving/transmitting data via that port shall be as specied for that port in an addressed S-modules manufacturers documentation (gure 17-1). (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 identies 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 Identier 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 commands. Furthermore, the message format of Data Transfer class commands are (in part) specic to the port addressed. Data transfer ports are dened 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 Identier may be followed by a port-specic 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 specied in clause 21. In the same clause, a number of recommended and permitted ports are dened.
17-1
IEEE Std 1149.5-1995
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 registers, on-module memory, or IEEE Std 1149.1 scan paths.
M-MODULE S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
This packet pair transfer is optional (may occur). This packet pair transfer is required.
PORT ID
NULL
Port-specic portion of message [port-specic addressing syntax, transfer of DATA packets, etc.]
NOTES 1The port-specific portion of Data Transfer class command message formats are treated on a port-by-port basis in clause 21. 2When a Data Transfer class 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 of the same message will take place (12.1.1f).
Figure 17-1Beginning of singlecast message format for Data Transfer class commands
17.2 Read Data command (0100000)

17.2.1 Specications Rules (a) The message format of a singlecast Read Data message shall be as dened in gure 17-2, including embedded text. (b) The message format of a multicast or broadcast Read Data message shall be as dened in gure 17-1 and shall have no port-specic part. (c) The execution of the Read Data command by an addressed S-module shall consist of the following, conducted in a manner dened by the S-module manufacturers user documentation: (i) selecting the port identied in the Read Data messages 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 dened in the S-module manufacturers module documentation; (iv) formatting all data read from the selected port into 16-bit segments and adding odd parity to form appropriate DATA packets; (v) transmitting resulting DATA packets to the M-module.
17-2
IEEE Std 1149.5-1995
17.2.2 Description The Read Data command is used to transfer any number of DATA packets from an uniquely addressed Smodule 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-specic addressing has been completed, non-NULL DATA packets are transmitted only from the addressed S-module while the M-module transmits NULL packets. Following the port-specic 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 implementationdependent. 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 available from the port.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
PORT ID
NULL
-- Port-specic portion of message -
NULL
DATA 0
NULL
DATA 1
In a Read Data message, zero or more DATA packets shall be transmitted by the S-module in the port-specific portion of the message. In a Read Data message, the M-module shall transmit only NULL packets in the port-specific portion of the message.
NULL
DATA n
NOTEWhen 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.1b). However, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1.1f).
Figure 17-2Singlecast message format for the Read Data command
17-3
IEEE Std 1149.5-1995
17.3 Write Data command (0100001)

17.3.1 Specications Rules (a) The message format of a Write Data message shall be as specied in gure 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 dened by the S-module manufacturers user documentation: (i) selecting the port identied in the Write Data messages Port ID packet;
(ii) writing all data in subsequently M-module transmitted DATA packets to the selected port; (iii) port-specic action on (or response to) such data. Permissions (c) An uniquely addressed S-module executing the Write Data command may, during the port-specic portion of the Write Data message, echo with zero packet latency on the MSD signal the DATA packets received on the MMD signal. 17.3.2 Description The Write Data command is used to transfer data from the M-module to a selected port on the addressed S-module(s). This data may include some initial port-specic addressing or programming usually followed by data to be transmitted to some function via the selected port. An uniquely addressed S-module may provide immediate feedback 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-module may receive a data bit on the MMD signal and place the same value on the MSD signal two cycles of the signal on MCLK later.
17-4
IEEE Std 1149.5-1995
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
This packet pair transfer is optional (may occur). This packet pair transfer is required. NOTES The port-specific portion of a Write Data message shall consist of zero or more packet pair transfers. 1An uniquely addressed S-module may echo data received from the M-module with a packet latency of zero instead of sending NULL packets. 2an S-module that is addressed by a broadcast or multicast message is forbidden to transmit data.
PORT ID
NULL
-- port-specic portion of message-
DATA 0
NULL or DATA 0
DATA 1
NULL or DATA 1
DATA n
NULL or DATA n
NOTEWhen a Write Data 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 of the same message will take place (12.1.1f).
Figure 17-3Singlecast message format for the Write Data command
17.4 Read/Write Data command (0100010)

17.4.1 Specications Rules (a) The message format of a Read/Write Data message shall be as specied in gure 17-4, including embedded text. (b) The execution of the Read/Write Data command by an uniquely addressed S-module shall consist of the following conducted in a manner dened by the S-module manufacturers user documentation: (i) selecting the port identied in the Read/Write Data messages 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 transmission via the selected port;
17-5
IEEE Std 1149.5-1995
(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-specic part of a Read/Write Data message shall be specied in the port documentation. 17.4.2 Description The Read/Write 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 gure 17-4, the message format is the same as for other Data Transfer class commands except that in the port-specic 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 Read/Write Data message, the S-module may assert the MPR signal until the port is ready to receive/transmit additional data. For Read/Write Data messages, packet latency has to be documented.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
PORT ID
NULL
-- Port-specic portion of message A Read/Write Data message shall contain L packet pair transfers of this type, 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 type. A Read/Write Data message shall contain L packet pair transfers of this type, where L is the packet latency of the port-specific portion of the message.
M-module DATA
NULL
M-module DATA
S-module DATA
NULL
S-module DATA
NOTEWhen a Read/Write Data 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 of the same message will take place (12.1.1f).
Figure 17-4Singlecast message format for the Read/Write Data command
17-6
IEEE Std 1149.5-1995

17.5.1 Specications Rules (a) An S-module shall respond to any of the Data Transfer class reserved commands in the manner specied for response to the Illegal command (16.17.1). 17.5.2 Description The command codes 01000110100111 are reserved for future revisions of this Standard. They are not to be dened by the user. The command codes for user-dened commands are identied and specied in table 15-1 and clause 20.
17-7
IEEE Std 1149.5-1995
17-8
IEEE Std 1149.5-1995
18. MTM-Bus Message Layer: Module Initialization and Self-Test (MIST) class commands (01010000101111)
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 messages causing unintentional entry of a module into a self-test mode. 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 specied in this Standard that ll one or other of these roles. Table 18-1Relationship and function of Core class, MIST class, and MICT class commands useful in initialization, resetting, and self-testing of an S-module
Required commands Core class Function Abort (16.2.1) Reset Initialize Slave Start Application Status (16.15.1) (16.13.1) (16.3.1) Reset Module Without SBIT (18.3.1) x Recommended commands MIST class Reset Module With SBIT (18.2.1) x MICT class Enable Module I/O (19.3.1) Disable Module I/O (19.2.1)
Module IBIT (18.4.1)
EMC required (table 15-1) 1. Abort previous command 2. Disable outputs 3. Reset status 4. Reset module 5. Start IBIT (SBIT) 6. Bring to documented initial state 7. Full functional operation 8. Enable outputs
x x
x x
x x
x x x x
x x x x
x x x x O O O x
x O x
x O O
x O O
Key: O 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. indicates that the action represented by that cell shall take place unless there is an active Disable Module command (19.2.1).
18-1
IEEE Std 1149.5-1995
18.1 General requirements for MIST commands

18.1.1 Specications Rules (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.1ce.
NOTEIf an S-module implements self-test, then the MFS and BSY bits of that S-modules Slave Status register are set prior to self-test initiation (9.2.1c) and remain set throughout the self-test (9.2.1d). Immediately following passage of a self-test, both the MFS and BSY bits of the S-modules Slave Status register are cleared (9.2.1e). If the S-module fails the self-test, then the BSY bit will be cleared (9.2.1e).
(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.
NOTEIt is beyond the scope of this Standard to specify the operation of a self-testing procedure or the type of action(s) required of an S-module (other than 18.1.1b) when a self-test fails.
(c) All MIST class commands described in this Standard shall cause the executing S-modules module I/O to be disabled (table 18-1) at the onset of their execution. (d) All MIST class commands that have the option of enabling an executing S-modules module I/O prior to termination of command execution shall never do so in cases in which an executing S-module has an active Disable Module I/O command (19.2.1).
NOTEAs dened in clause 19, an S-modules having an active Disable Module I/O command means that that S-module has received a Disable Module I/O message, has disabled its module I/O, and has not executed an Enable Module I/O command since that time. S-modules are required (19.2.1) to maintain a record of whether or not they have an active Disable Module I/O command.
(e) All module self-test procedures shall be fully documented by the manufacturer of an S-module.
NOTE9.4.1e is a recommendation that the manufacturer of an S-module implementing self-test (18.1.1a) should provide a means accessible by an appropriate command that would indicate whether self-test has run to completion without detection of a fault. If an indicator of self-test failure 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. A second indicator is needed to resolve the ambiguity. It is permitted to place such an indicator as a bit in the Bus Error register (9.3.1i).
(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 (0101000)
18.2.1 Specications Rules (a) The message format of a Reset Module With SBIT command shall be as depicted in gure 18-1.
18-2
IEEE Std 1149.5-1995
(b) Upon its S-Controllers 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-modules status registers as specied in 16.3.1c;
(ii) shall perform any other necessary reset of the S-module;

NOTEModule I/O is disabled (18.1.1c).
(iii) consequent to the actions described in 18.2.1b(i) and 18.2.1b(ii), shall execute the S-modules module initialization and SBIT procedures.
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2This Standard recommends (9.3.1i; 9.4.1e) that a bit in the Bus Error register or 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 (9.2.1).
(c) Consequent to the actions specied in 18.2.1b, 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 dened by the S-modules manufacturers documentation. (d) Consequent to the action described in 18.2.1c, if an S-module executing the Reset Module With SBIT command does not implement recommendation 18.2.1f, the S-module shall wait in a stable mode as documented by that S-modules manufacturer. (e) The manufacturer of an S-module implementing the Reset Module With SBIT command shall document fully (i) maximum time of execution of the command;
(ii) if permission 18.2.1g is implemented, the period within the time documented according to 18.2.1e(i) that the S-modules 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-modules module I/O (limited by 18.1.1d);
(ii) initiate full functional operation of the S-module.

NOTEThe 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 1149.5-1995
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 commands sent during the self-testing period. If a given S-module implements permission 18.2.1g, the M-module 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.
HEADER
PACKET COUNT
ACKNOWLEDGE
NOTEAfter an addressed S-modules S-Controller enters its EOM Slave Controller state, SBIT execution begins.
NOTEWhen a Reset Module With SBIT 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 of the same message will take place (12.1.1f).
Figure 18-1Singlecast message format for the Reset Module With SBIT command
18.3 Reset Module Without SBIT command (0101001)

18.3.1 Specications Rules (a) The message format of a Reset Module Without SBIT message shall be as depicted in gure 18-2. (b) Upon its S-Controllers 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-modules status registers as specied in 16.3.1c;
(ii) shall perform any other necessary reset of the S-module; (iii) shall bring the S-module to a known initial state as dened by S-module documentation.
18-4
IEEE Std 1149.5-1995
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2At the onset of execution of this commandprior to the actions prescribed in 18.3.1bthe S-modules module I/O is disabled (18.1.1c).
Recommendations (c) As part of the execution of the Reset Status Without SBIT command, an S-module should both (i) enable the S-modules module I/O (limited by 18.1.1d);
(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
PACKET COUNT
ACKNOWLEDGE
NOTEWhen a Reset Module Without SBIT 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 of the same message will take place (12.1.1f).
Figure 18-2Singlecast message format for the Reset Module Without SBIT command
18.4 Module Initiated Built-In Test (Module IBIT) command (0101010)

18.4.1 Specications Rules (a) The message format of a Module IBIT message shall be as dened in gure 18-3. (b) Upon its S-Controllers 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-modules status registers as described in 16.3.1c;
(ii) shall perform any other necessary reset of the S-module;

NOTEThe S-module will also disable its module I/O (18.1.1c) at the onset of this commandprior to actions listed in 18.4.1b.
18-5
IEEE Std 1149.5-1995
(iii) consequent to the actions of 18.4.1b(i), shall run the module IBIT.
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2This Standard recommends (9.3.1i; 9.4.1e) 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 (9.2.1).
(c) If the Module IBIT command, as implemented in a given S-module, can cause any of that S-modules Module Status register bits or Additional Status register bits to change state, this shall be documented in the S-modules manufacturers documentation. (d) If recommendation 18.4.1h is implemented in a given S-module, (i) recommendation 18.4.1g shall be implemented in that S-module;
(ii) both the actions specied in 18.4.1h shall be implemented and shall be performed in the order listed in 18.4.1h. (e) If recommendation 18.4.1g is implemented in a given S-module, then during execution of the Module IBIT command and consequent to the action described in 18.4.1g, if that S-module does not implement recommendation 18.4.1h, the S-module shall wait in a stable mode as documented by that S-modules manufacturer. (f) The manufacturer of an S-module implementing the Module IBIT command shall document fully (i) maximum time of execution of the command;
(ii) the period during this time (18.4.1f(i)) in which the S-modules outputs will be disabled if the S-module does not have an active Disable Module I/O command; (iii) S-module actions should the IBIT activated by execution of this command fail; (iv) S-module status and operation at termination of execution of the Module IBIT command with the S-module having passed the self-test in cases in which neither recommendation 18.4.1g nor permission 18.4.1h are implemented. Recommendations (g) Consequent to the actions specied in 18.4.1b, 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 dened by the S-modules manufacturers documentation.
NOTEThe initial state of 18.4.1g could be the same state that results from execution of the Initialize Application 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-modules module I/O (limited by 18.1.1d);
(ii) initiate full functional operation of the S-module.
18-6
IEEE Std 1149.5-1995
NOTEAn 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
PACKET COUNT
ACKNOWLEDGE
After an addressed S-modules S-Controller enters its EOM Slave Controller state, the S-module is reset. Then that S-modules outputs are disabled; and IBIT is initiated. Module IBIT begins execution.
NOTEWhen a Module IBIT 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 of the same message will take place (12.1.1f).
Figure 18-3Singlecast message format for the Module IBIT command
The Module IBIT command causes the S-module to be reset as dened in 16.3.1b prior to executing module IBIT so that status changes following the Module IBIT command reect the results of the self-test.

18.5.1 Specications Rules (a) An S-module shall respond to any of the MIST class reserved commands in the manner specied for response to the Illegal command (16.17.1). 18.5.2 Description The command codes 01010110101111 are reserved for future revisions of the MTM-Bus. They are not to be dened by the user. The command codes for user-dened commands are identied and specied in table 15-1 and clause 20.
18-7
IEEE Std 1149.5-1995
18-8
IEEE Std 1149.5-1995
19. MTM-Bus Message Layer: Module I/O Control and Test (MICT) class commands (01100000110111)
Module I/O Control and Test (MICT) class commands are provided to standardize a mechanism for testing interconnections between modules. The rst two commands, Disable Module I/O (19.2.1) and Enable Module I/O (19.3.1), are general purpose commands that have use beyond module interconnect testing (table 18-1). The remaining commands are specic to performing tests of backplane interconnects. The model of non-MTM-Bus S-module I/O that underlies the MICT class command denitions is dened 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 I/O is shortened to S_module I/O or module I/O. Likewise, references to particular types of non-MTM-Bus S-module I/O 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 functional 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.1]); controlling the direction of S-module bidirectional signals (Force Module Outputs command [19.4.1]); dening values to be driven by S-module outputs and S-module bidirectional signals acting as outputs (Force Module Outputs command [19.4.1], Sample Module With Force command [19.8.1]); establishing the set of values intended to be driven onto the backplane for test purposes while the signals are in an undriven condition (Force Module Outputs command [19.4.1]); actually driving such values onto the backplane and sampling resultant values on backplane nets (Force Module Outputs command [19.4.1], Enable Module I/O command [19.3.1]); using S-module input signals to sample the values on backplane nets (Sample Module I/O commands [19.5.1 through 19.8.1]); returning an S-module to normal system operation (Release Module I/O command [19.9.1], Enable Module I/O command [19.3.1]). The Disable Module I/O command is unusual among the commands dened in this Standard in that its having 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.
NOTEIf a question occurred as to whether a given S-module had an active Disable Module I/O command, it could always be resolved by the sending of an Enable Module I/O or a Disable Module I/O 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.5.1g) could be used as an indicator of whether the module has an active Disable Module I/O command or not.
Since all of the commands but the Release Module I/O 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
1:
2: 3:
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 operational use of the modules.) Also, it is necessary to be sure that other S-modules will not use backplane signals required for the interconnect test during that test. Disable outputs (using the Disable Module I/O command) of all modules that will be involved in, or affected by, the intended testing (to ensure that there will be no conicting 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 module output drivers.)
NOTEChip resources designed to support IEEE Std 1149.1 based testing of a modules primary I/O might be used to support intermodule interconnect testing.
4: 5: 6:
Using the Enable Module I/O command, enable the outputs of the S-modules so that the test stimulus is applied to the backplane interconnect. Capture the values propagated through the backplane at S-module inputs using one of the Sample 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: Disable outputs of all modules that were involved in, or affected by, the testing using the Disable Module I/O command. 8: Release control of the module I/O control signals and module output values to the module functional circuitry using the Release Module I/O command. 9: Restore the modules functional circuitry to the desired system state using appropriate MTM-Bus commands (e.g., Initialize Application, Reset Module with SBIT, Reset Module Without SBIT). 10: Restore the module I/O to the system functionality using the Enable Module I/O command. The commands described in this Standard are not dened based on any assumptions concerning hardware implementation. Hardware implementations similar to that specied for chips in IEEE Std 1149.1 could be used. Another option would be the use of on-module software.
19.1 MICT class commandsgeneral requirements

19.1.1 Specications Rules (a) The purpose of the MICT class commands shall be to provide the ability to verify backplane (intermodule) 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.
NOTEAll MICT class commands dened in this Standard, with the exception of the Release Module I/O 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
IEEE Std 1149.5-1995
(ii) S-module I/O 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 dene for every module I/O 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 dened in 19.1.1b 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-modules manufacturers documentation shall explicitly state the relationship between the MICT-testable module signals of that Smodule 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-modules manufacturers 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 I/O signal may operate as an output, any output enable control signal or direction control signal for that MICT-testable module I/O 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 (D) shall be mapped to the S-module I/O signal(s) controlled by C (D). (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 contiguous in that bit string.
NOTEThe situation in which multiple bits would represent a signal value could arise if that value were represented 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 I/O 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 I/O 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 I/O signals in question) a single MICT-testable module bidirectional signal direction control signal, S,
19-3
IEEE Std 1149.5-1995
(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 I/O signals in the set. (k) The time required for each MICT class command to complete execution shall be noted in the module documentation. (l) 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/ O of that S-module disabled after the execution of some command, then the Enable Module I/O command (19.3) shall be implemented in that S-module.
NOTEIn a given S-module, if the Disable Module I/O command is implemented, the Enable Module I/O command has to be implemented in that S-module.
(n) In a given S-module, if the Force Module Outputs command (19.4) or the Sample Module With Force command (19.8) is implemented then the Release Module I/O command (19.9) shall be implemented in that S-module. 19.1.2 Description An S-module implementing any MICT class command will fully document its operation including the set of S-module outputs controlled, the set of S-module inputs sampled, and specics of the commands message format that are not xed by this Standard.
19.2 Disable Module I/O command (0110000)

19.2.1 Specications Rules (a) The message format of a Disable Module I/O message shall be as depicted in gure 19-1. (b) An addressed S-module receiving a Disable Module I/O message immediately preceded by an EMC message, shall disable all module I/O drivers/transmitter/transformers.
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2The term module I/O has been dened to exclude MTM-Bus signals (introduction to clause 19).
(c) Execution of the Disable Module I/O command shall not be construed to be concluded until all module I/O of an S-module executing the command are fully disabled.
NOTEThe important consequence of this rule is that the BSY bit of an S-modules Slave Status register becomes an indicator for the complete disabling of the S-modules module I/O.
19-4
IEEE Std 1149.5-1995
(d) Once an S-module has executed the Disable Module I/O command, those drivers/transmitters/transformers disabled by execution of the command (19.2.1b) shall remain disabled until the S-module executes the Enable Module I/O command (19.3). (e) An S-module that has executed the Disable Module I/O command and has not subsequently executed the Enable Module I/O command (19.3) shall be said to have an active Disable Module I/O command.
NOTEHaving an active Disable Module I/O command has absolute precedence over all other commands related to S-module I/Oexcept for the Enable Module I/O 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 documented by that S-modules 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 I/O 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 failure or some other failure that is difcult 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 I/O command is shown in figure 19-1. The Disable Module I/O command has to be preceded immediately by the Enable Module Control command. 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 efcient (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.
HEADER
PACKET COUNT
ACKNOWLEDGE
Module I/O disabled
NOTEWhen a Disable Module I/O message is broadcast or multicast, no S-module transmits anything (12.1.1d). Howe er, normal S-module processing that would be initiated by a singlecast of the same message will take place (12.1.1f).
Figure 19-1Singlecast message format for a Disable Module I/O message
19-5
IEEE Std 1149.5-1995
19.3 Enable Module I/O command (0110001)

19.3.1 Specications Rules (a) The message format of an Enable Module I/O message shall be as depicted in gure 19-2. (b) An addressed S-module receiving an Enable Module I/O message that has been immediately preceded by an EMC message, shall (i) enable any module I/O drivers/transmitters/transformer that is not currently disabled by nonMTM-Bus function(s) of that S-module;
(ii) return to normal operation any module input that is not blocked from affecting S-module circuitry by non-MTM-Bus function(s) of that S-module;
(c) An S-module that has executed an Enable Module I/O command shall not have an active Disable Module I/O command; (d) Execution of the Enable Module I/O command shall not be construed to be concluded until all module I/O of an S-module executing the command are fully enabled;
NOTEThe BSY bit of the Slave Status register (9.2.1a; table 9-1) will be set when an Enable Module I/O command begins to execute and will not be cleared until all module I/O of an S-module executing the command 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 modules I/O to the functional output enable control signals internal to the S-module (reversing the override action created by the Disable Module I/O command). In addition to supporting module self-test and module interconnect testing, it provides a useful capability (in combination with the Release Module I/O command [19.9.1]) to quickly restore S-modules (e.g., as a group) to normal functional control of module I/O. 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 I/O command is shown in figure 19-2. An Enable Module I/O message has to be preceded immediately by an EMC message. As in the case of the Disable Module I/O command (19.2.2), implementing this command as a single command (rather than a series of other MTM-Bus commands) is strongly recommended.
HEADER
PACKET COUNT
ACKNOWLEDGE
Module I/O enabled
NOTEWhen an Enable Module I/O 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 of the same message will take place (12.1.1f).
Figure 19-2Singlecast message format for an Enable Module I/O message
19-6
IEEE Std 1149.5-1995
19.4 Force Module Outputs command (0110010)

19.4.1 Specications Rules (a) The message format of a Force Module Outputs message shall be as depicted in gure 19-3.
NOTEThe text of gure 19-3 is incorporated as part of 19.4.1a.
(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).
NOTEThe test data to be applied as a result of execution of the Force Module Outputs command can be provided previously in some other manner (gure 19-3).
(c) An S-modules manufacturers 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 Smodule next executes the Release Module I/O command (19.9.1); (iv) force the S-modules 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.1c).
(e) An addressed S-module (i) 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 Smodule next executes the Release Module I/O 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
(v) preserve the test data transmitted in such a manner that, barring intervening execution of commands listed in 19.4.1e(iv), the S-module can force the test pattern data onto its module outputs after executing an Enable Module I/O (19.3.1) command.
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2The Release Module I/O command returns module I/O to full functional operation and test data that has not been forced on module outputs prior to the execution of the Release Module I/O command becomes irrelevant.
(f) Execution of the Force Module Outputs command by an S-module shall not be construed to be completed until all the S-modules 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.
NOTEThe BSY bit of the Slave Status register (9.2.1a; table 9-1) will be set when a Force Module Outputs command begins to execute and will not be cleared until all the S-modules 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.
19.4.2 Description The Force Module Outputs command is used to directly control the values on the S-modules outputs to simplify module interconnect testing. Such control of module I/O is mutually exclusive with normal functional control of the same I/O. The message format for the Force Module Outputs command is shown in figure 19-3. A Force Module Outputs message has to be preceded immediately by an EMC message.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
MDATA 1
NULL
MDATA 2
NULL
MDATA 3
NULL
The Force Module Outputs command may or may not supply the test data to be applied at S-module outputs. When the test values to be applied are provided in the same message as is the command, the entire message format illustrated shall be used. Otherwise, only the portion of the message format above this line shall be used.
MDATA n
NULL
NOTEWhen 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-3Singlecast message format for a Force Module Outputs message
19-8
IEEE Std 1149.5-1995
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.1), another Force Module Outputs 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.
NOTEIn applications requiring the most secure approach, a Force Module Outputs message should be preceded by a Disable Module I/O 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].)
19.5 Sample Module Inputs commands (01100110110101)general requirements

It is recommended that one or all of the three Sample Module Inputs commands dened by this Standard be implemented. The three commands are Sample Module No Change (0110011), Sample Module Dont Care (0110100), 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 sampled data to be sent back to the M-module, but the S-modules 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 causes module inputs current values to be sampled. The M-module then transmits DATA packets to the S-module containing new test data values (as in the Force Module Outputs command [19.4.1]) while the just sampled test result values are being transmitted from the S-module to the M-module. During execution of the Sample Module Dont Care command, the values on the S-modules outputs are not constrained in any way. 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 classied as critical control commands.
NOTEThe 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 I/O 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 Specications Rules (a) For an S-module implementing a Sample Module Inputs command, that S-modules manufacturers 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
IEEE Std 1149.5-1995
(ii) the format and contents of such DATA packets (19.5.1a(i)); (iii) the number of DATA packets needed to transfer a single test result (sampled data) vector from the S-module to the M-module; (iv) the format and content of such DATA packets (19.5.1a(iii)); (v) the maximum length of the period in which data sampling (19.5.1b(i)) occurs. (b) Upon receiving a Sample Module Inputs message immediately preceded by an EMC message, an Smodule addressed by both these messages shall (i) sample the current values of that S-modules 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 transmission of the PACKET COUNT packet (otherwise);
NOTEThe importance of 19.5.1a(v) becomes clear here. The M-module has to take count of the time that the S-module requires for samplingby not causing a state transition in the S-modules S-Controller until sampling is over.
(ii) maintain stable values on all module outputs during the sampling period (19.5.1b(i)); (iii) subsequent to the action of 19.5.1b(i), transmit the sampled values (test result data) to the Mmodule or store them to be recovered in some other manner.
NOTES 1Error handling in the case in which the necessary EMC message does not precede a critical control message is described in 11.9.1b. 2Figures 19-4 and 19-5 provide that test data need not be transmitted as part of a Sample Module Inputs message.
(c) 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.1a(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 1It is a consequence of these requirements that any given singlecast Sample Module Inputs message involves transmission of one test vectors worth of sampled data to the M-module. Likewise, any given Sample Module Inputs message involves the transmission of, at most, one test vectors worth of new test input data to the addressed S-module(s). 2The BSY bit of the Slave Status register (9.2.1a; table 9-1) will be set when a Sample Module Inputs command begins to execute and will not be cleared until all three criteria listed in 19.5.1c are met.
Recommendations (d) S-modules that implement Module Interconnect Testing should implement at least one of the three Sample Module Inputs commands dened in 19.6.1 through 19.8.1.
19-10
IEEE Std 1149.5-1995
19.6 Sample Module No Change command (0110011)

19.6.1 Specications Rules (a) The format of a Sample Module No Change command shall be as depicted in gure 19-4.
(b) An addressed S-modules 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 (gure 19-4) in sufcient quantity (19.5.1a(iii)) to allow transmission by an addressed S-module of all sampled data.
M-MODULE S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
NULL
SDATA 1
NULL
SDATA 2
NULL
SDATA 3
Sample Module messages may or may not recover test result data. When test result data are transmitted in the same message as is the command, the entire message format illustrated shall be used. Otherwise, only the portion of the message format above this line shall be used.
NULL
SDATA n
NOTEWhen a Sample Module No Change message or a Sample Module Dont Care 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 of the same message will take place (12.1.1f).
Figure 19-4Singlecast message format for a Sample Module No Change message or a Sample Module Dont Care message
19.7 Sample Module Dont Care command (0110100)

19.7.1 Specications Rules (a) The format of a Sample Module Dont Care message shall be as depicted in gure 19-4.
19-11
IEEE Std 1149.5-1995
(b) During execution of the Sample Module Dont 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 Dont Care message, the M-module shall transmit NULL packets (gure 19-4) in sufcient 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 Specications

(a) The format of a Sample Module With Force message shall be as depicted in gure 19-5.
M-MODULE
S-MODULE
HEADER
PACKET COUNT
ACKNOWLEDGE
Force DATA 1
Sample DATA 1
Force DATA 2
Sample DATA 2
Force DATA 3
Sample DATA 3
Sample Module With Force messages may or may not include the transmission of test data. When test data are transmitted in the same message as is the command, the entire message format illustrated shall be used. Otherwise, only the portion of the message format above this line shall be used.
Force DATA n
Sample DATA n
NOTEWhen a Sample Module With Force 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 of the same message will take place (12.1.1f).
Figure 19-5Singlecast 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-modules S-Controllers 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
IEEE Std 1149.5-1995
(i)
shall cause S-module functional control of MICT-testable signals to be overridden until the Smodule next executes the Release Module I/O command (19.9.1);
(ii) unless permission 19.8.1f is implemented in that S-module, shall maintain the values on module outputs constant throughout the message until the later of two events(1) the newly supplied test input values are stable and ready to be forced onto the module output signals or (2) the addressed S-modules S-Controller enters its EOM Slave Controller state. (d) In an S-module implementing permission 19.8.1f, the S-module outputs have to be enabled as soon as possible after the condition of 19.8.1c(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.1c are fully achieved and (if the S-module implements permission 19.8.1f) the requirement of 19.8.1d 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.1c(i) has not yet been achieved.
19.9 Release Module I/O command (0110110)

19.9.1 Specications Rules (a) The message format of the Release Module I/O command shall be as depicted in gure 19-6. (b) Upon receipt of a Release Module I/O message, an addressed S-module (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 I/O. (c) Execution of the Release Module I/O command shall not be construed to be complete until an addressed S-modules module I/O is fully returned to functional control.
NOTEThe BSY bit of the Slave Status register (9.2.1a; table 9-1) will be set when a Release Module I/O command begins to execute and will not be cleared until an addressed S-modules module I/O is fully returned to functional control.
19.9.2 Description The message format for the Release Module I/O command is shown in figure 19-6.
19-13
IEEE Std 1149.5-1995
HEADER
PACKET COUNT
ACKNOWLEDGE
Module I/O released
NOTEWhen a Release Module I/O 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 of the same message will take place (12.1.1f).
Figure 19-6Singlecast message format for a Release Module I/O command
The Release Module I/O 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.1)] to functional control. If an S-module that has executed the Release Module I/ O 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.1 Specications Rules (a) An S-module shall respond to any of the MICT class reserved commands in the manner specied for response to the Illegal command (16.17.1). 19.10.2 Description The reserved commands 01101111001111 are reserved for future revisions of the MTM-Bus. They are not to be dened by the user. The command codes for user-dened commands are identied and specied in table 15-1 and clause 20.
19-14
IEEE Std 1149.5-1995
20. MTM-Bus Message Layer: Standard Extension class commands (10100001011111) and User-Dened class commands (11000001111110)
20.1 Standard Extension class commands (10100001011111)
20.1.1 Specications Rules (a) The Standard Extension commands (having command codes 10100001011111) 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 dened 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 10100001011111 shall be administered by the IEEE Standards Ofce (Piscataway, New Jersey) or an organization to which the IEEE Standards Ofce 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.
NOTESuch protection might be provided by means of the 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-Dened class commands (11000001111110)

20.2.1 Specications Rules (a) The User-Dened commands (11000001111110) shall operate as dened by the user. (b) If the user has not dened these commands or a subset of these commands, the undened commands shall have S-module response as specied for the Illegal command (16.17.1). (c) All User-Dened commands shall be designated as public or private commands. (d) The command codes and operation of all User-Dened public commands shall be fully documented.
20-1
IEEE Std 1149.5-1995
(e) The command codes for User-Dened private commands shall be documented. Recommendations (f) User-dened private commands that may cause undesirable S-module side-effects if they are not properly used should be protected against accidental use.
NOTESuch 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 11000001111110 are available for denition by the user. If they are not dened, then they have to be treated as illegal commands. User-dened 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 transferred. Private commands may be used by the manufacturer for testing or debug and may cause unpredictable 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 the command is executed in an incorrect environment or at an inappropriate time. This protection could be by means of any of a number of methods including using the Enable Module Control command (16.10.1).
20-2
IEEE Std 1149.5-1995
21. Data transfer ports

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 modulespecic ports.
21.1 Data transfer portsgeneral requirements

21.1.1 Specications Rules (a) Each data transfer port within an S-module shall be identied by a 16-bit port identier (17.1.1). Table 21-1Reserved port identiers for Data Transfer class commands
Port identier (Hex) 00000003 00040007 Fault logs Test Data Storage Error/Status registers Slave Status register Bus Error register Module Status register Additional Status registers ID registers Manufacturer ID port Module Manufacturer port User Identication ports Access to IEEE Std 1149.1 bus(es)
Port type
Specication Recommended (21.3) Permitted (21.4) Recommended (21.5)
0008 0009 000A 000B
000C 000D 000E000F 0010001F
Recommended (21.6) (21.7) (21.8) Recommended when such buses are present (21.10 through 21.12) Permitted Recommended (9.1.1d; 21.9) Reserved Reserved Permitted
0020007F 0080 00810F00 0F010FFF 1000FFFF
Access to other module buses Access to status register backup means Reserved for future denition Reserved for use of other standards bodies User-dened
NOTESome port types may not support all of the Data Transfer class commands.
(b) Port identiers 0000 HEX through 0FFF HEX shall be reserved for specic port types precisely as shown in table 21-1 and as follows: (i) Assignment of Port identiers 0081 HEX through OF00 HEX shall be made as required by future supplements to, or revisions of, this Standard.
21-1
IEEE Std 1149.5-1995
(ii) Assignment of Port identiers 0F01 HEX through OFFF 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 identier(s) shall lie within the associated port identier 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 rst packet pair of the port-specic part of the message (17.1.1c; gure 17-1), the selected port shall report an error (11.8.1). (e) Manufacturer provided documentation of an S-module shall identify all supported port identiers.
NOTEFurther documentation requirements for implemented ports are described in 21.2.
Recommendations (f) S-modules should provide access to one or more Module/Fault Log ports, as specied in 21.3. (g) S-modules should provide access (as specied in 21.5) to the Slave Status register, Bus Error register, Module Status register, and additional status register ports. (h) S-modules should provide access to Identication register ports as specied in 21.6 through 21.8. (i) When one or more instances of an IEEE Std 1149.1 bus are present on an S-module, that S-module should provide access to such buses via ports as specied in 21.10 through 21.12. (j) If an S-module provides data backup means as recommended in 9.1.1d, that S-module should provide access to these backup means via an access to the status register backup meansError/ Status Shadow register port as specied in 21.9. Permissions (k) S-modules may provide access to Test Data Storage ports (21.4). (l) S-modules may provide access to ports for module buses. (m) S-modules may provide access to additional user-dened ports. (n) A port may provide access via logical or physical addressing to an individual register or memory. (o) 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). (q) Port addressing may be dened 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 read/write access to ports within S-modules. These ports are identied by a 16-bit port identier that is provided in the PORT ID packet of a Data Transfer class message.
21-2
IEEE Std 1149.5-1995
A data transfer port can be used to provide access to a variety of on-module resources. An individual port identier (port ID) may provide access to an individual register, memory, or even an on-module bus. Table 21-1 lists the standardized port identiers. Standardized port IDs are provided to Module/Fault Logs, Error/ Status registers, and Identication registers. The format of data transfers to these standardized ports are dened in the following clauses. No port will remain selected after the termination of a message (17.1.1d).
21.2 Port denition and documentation requirements

21.2.1 Specications Rules (a) The denition of a port shall completely specify the port-specic 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 Read/Write command, (i) the packet latency of returning data shall be specied;
(ii) any order dependency of reading and writing shall be specied. (c) The denition 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 appropriately by the M-module. The denition of a port may be viewed as a programmers model of the port. Packet latency is further detailed in 17.4.2 and gure 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-specic 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 reection of packet latency; or such transmission may be required at sub-message boundaries to allow completion of some function in the S-module.
21.3 Module/Fault log port(s) (0000 HEX 0003 HEX)

21.3.1 Specications
Rules (a) A Module/Fault Log port shall provide access to non-volatile read/write memory. (b) A Module/Fault Log port shall support the Read Data and Write Data commands.
21-3
IEEE Std 1149.5-1995
NOTEAttempting to access ports having port identiers 0000 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 identiers 0000 HEX through 0003 HEX using any Data Transfer class command not supported by the selected port (21.2.1a) will cause the PTE bit in the Bus Error register to be set (11.8.1f).
(c) If permission 21.3.1d is implemented in a given S-module, then the read action shall precede the write action. Permissions (d) A Module/Fault Log port may support the Read/Write Data command. 21.3.2 Description Typically, a Module/Fault Log is implemented as non-volatile memory and is used for the storage of module-specic data including test patterns, test signatures, and fault log data.
21.4 Test Data Storage ports (0004 HEX 0007 HEX)

21.4.1 Specications (a) A Test Data Storage port shall provide access to non-volatile read/write memory. (b) A Test Data Storage port shall support the Read Data and Write Data commands.
NOTEAttempting to access ports having port identiers 0004 HEX through 0007 HEX 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 ports having port identiers 0004 HEX through 0007 HEX using any user-dened Data Transfer class command not supported by the selected port (21.2.1a) will cause the PTE bit in the Bus Error register to be set (11.8.1f).
(c) If permission 21.4.1d is implemented in a given S-module, then the read action shall precede the write action. Permissions (d) A Test Data Storage port may support the Read/Write Data command.
21.4.2 Description
A Test Data Storage port is typically used to gain access to memory in which module-specic 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 memory in which to store all data for testing all modules. This makes it easier to develop a system-level test strategy that is closer to plug and play than would be possible otherwisea new S-module can be tested in a system without needing system-level test (even test and diagnostic) program updating.
21-4
IEEE Std 1149.5-1995
21.5 Error/Status register ports (0008 HEX 000B HEX)

21.5.1 Specications Rules (a) An Error/Status register port shall support the Read Data and Write Data commands.
NOTEAttempting to access ports with port identiers 0008 HEX through 000B HEX 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 ports having port identiers 0008 HEX through 000B HEX using any other Data Transfer class command not supported by the selected port (21.2.1a) 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 IDs 0008 HEX through 000A HEX) using a singlecast Read Data message shall not change the values in the registers.
NOTEThe BMR bit (bit <10>) 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 manufacturers documentation. (d) If permission 21.5.1h is implemented in a given S-module, the read function shall occur before the write function. (e) If permission 21.5.1g is implemented for a given Error/Status register port having port ID 0008, 0009, or 000A, that S-module shall provide the data from the MTM-Bus register for which the given Error/Status register port is reserved in the S-module transmitted DATA packet following receipt of the PORT ID packet (17.1.1a; gure 17-1). (f) If permission 21.5.1g 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 specied in the case of a Read Status message (16.1.1d).
NOTEIf, say, the Bus Error register is accessed rst, 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 rst then the Slave Status register and Bus Error register are both inaccessible in the current message.
Permissions (g) 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 Read/Write Data command.
21.5.2 Description
Ports with port IDs 0008 HEX through 000B HEX have been reserved for accessing S-module status registers. Ports with port IDs 0008 HEX, 0009 HEX, and 000A HEX will provide access to the Slave Status register, Bus Error register, and Module Status register, respectively. An S-modules manufacturer may provide access to additional status registers via the port having port ID 000B HEX. Contents of S-module
21-5
IEEE Std 1149.5-1995
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 dened in 21.5.1a, accessing ports with port IDs 0008 HEX through 000A 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 denition of the Read Status command (16.1.1d), it is required of an S-module that all S-module status registers may be accessed by the M-module in a single command. A sequence for transmission of the contents of the status registers is dened. Permission 21.5.1g and rule 21.5.1f 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.1d. Moreover, the sequence of access is the same as it is for the Read Status command.
21.6 MTM-Bus Interface Manufacturer ID port (000C HEX)

21.6.1 Specications Rules (a) An MTM-Bus Interface Manufacturer ID port shall support the Read Data command.
NOTEAttempting to access the port having port identier 000C HEX 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 ports having port identier 000C HEX using any other Data Transfer class command not supported by this port (21.2.1a) will cause the PTE bit in the Bus Error register to be set (11.8.1f).
(b) An Interface Manufacturer ID port shall not support any Data Transfer class command that would permit alteration of the codes that can be read from that port.
NOTEIn particular, this rule forbids an Interface Manufacturer ID ports supporting the Write Data and Read/Write Data commands. It is recommended, that a mechanism not involving this port be provided to allow modication of a user-programmable ID code if such is implemented in a given S-modules MTM-Bus interface (21.6.1g).
(c) The port-specic part of the message format for Read Data message accessing an MTM-Bus Interface Manufacturer ID port shall be as dened in gure 21-1. (d) The format of DATA packets returned by an S-module in the port-specic part of a Read Data message selecting a MTM-Bus Interface Manufacturer ID data shall be as shown in gure 21-2. (e) If an S-module MTM-Bus interface is implemented within a component containing an IEEE Std 1149.1 vendor-dened ID code, accessible by the IEEE Std 1149.1 IDCODE instruction, the rst and second S-module transmitted DATA packets in the port-specic part of a Read Data message accessing an MTM-Bus Interface Manufacturer ID port shall contain the IEEE Std 1149.1 vendordened ID code formatted as shown in gure 21-2. (f) If both (i) the S-module MTM-Bus interface is implemented within a component containing an IEEE Std 1149.1 user-programmable ID code accessible by the IEEE Std 1149.1 USERCODE instruction and
21-6
IEEE Std 1149.5-1995
(ii) permission 21.6.1h 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.1h is implemented in a given S-module, a mechanism should be provided for writing the user-programmable ID code.
NOTEFull documentation of such a mechanism is required (22.1.1b).
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 (000C HEX). 21.6.2 Description
M-MODULE S-MODULE MTM-Bus Interface Manufacturer Identier (lsw) MTM-Bus Interface Manufacturer Identier (msw) optional user programmable identier (lsw) optional user programmable identier (msw)
NULL
PACKET 1
NULL
PACKET 2
NULL
PACKET 3
NULL
PACKET 4
Figure 21-1Port-specic portion of sInglecast message format for a Read Data message selecting an MTM-Bus Interface Manufacturer Identication port
Port 000C is reserved for accessing identication 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 000C is only accessible using the Read Data command. When this port is accessed, the addressed S-module returns data that identies the manufacturer of the MTM-Bus interface 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-modules MTM-Bus interface. The format of the manufacturer ID is shown in gure 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-dened ID code (as specied by IEEE Std 1149.1-1990 and accessed by the IEEE Std 1149.1 IDCODE instruction), then the value of that same vendor-dened 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 specied 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
value of that same user-programmable ID code is returned as the MTM-Bus user-programmable ID (3rd and 4th packets following port ID).
4 bits Packet 1 Part no. (lsbs)
11 bits Manufacturers code
1 bit 1
MTM-Bus manufacturer identifier = IEEE Std 1149.1 manufacturer identity code (lsw)
4 bits Packet 2 Version
12 bits Part no. (msbs)
MTM-Bus manufacturer identifier = IEEE Std 1149.1 manufacturer identity code (msw)
16 bits Packet 3 User-specified format (lsw) User-programmable identifier (lsw)
Packet 4
16 bits User-specified format (msw) User-programmable identifier (msw)
Figure 21-2Packet formats for S-module Interface Manufacturer Identication port
21.7 Module Manufacturer port (000D HEX)

21.7.1 Specications Rules (a) A Module Manufacturer port shall provide access to the Module Manufacturer ID code having a format as specied for the Block Identier (Organizationally Unique Identier [OUI] in IEEE Std 802-1990). (b) A Module Manufacturer port shall support the Read Data command.
NOTEAttempting to access the port having port identier 000D HEX 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 identier 000D HEX using any other Data Transfer class command not supported by this port (21.2.1a) will cause the PTE bit in the Bus Error register 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.
NOTEIn particular, this rule forbids a Module Manufacturer ports supporting the Write Data and Read/ Write Data commands. It is recommended, that a mechanism not involving this port be provided to allow modication of a user-specied Module ID code if such is implemented in a given S-modules MTM-Bus interface (21.7.1f).
21-8
IEEE Std 1149.5-1995
(d) The port-specic part of the message format for a Read Data message selecting a Module Manufacturer port shall be as dened in gure 21-3. (e) The format of the DATA packets returned by the S-module in the port-specic part of a Read Data message selecting a Module Manufacturer port shall be as shown in gure 21-4. Recommendations (f) A 16-bit User-Specied Module ID code should be transferred following the Module Manufacturer ID code (gures 21-3 and 21-4). (g) An S-module implementing a Module Manufacturer port and implementing recommendation 21.7.1f should provide a mechanism for write access to the optional User-Specied Module ID code.
NULL NULL
PACKET 1 PACKET 2
Module Manufacturer ID code (lsw) Module Manufacturer ID code (msw) Optional User-Specied Module ID code
NULL
PACKET 3
Figure 21-3Port-specic portion of singlecast message format for a Read Data message selecting a Module Manufacturer Identication 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 Identier or Organizationally Unique Identier (OUI). The OUI is a 24-bit code, assigned by the IEEE, that unambiguously identies manufacturers implementing IEEE Std 802-1990.4 This port provides read access only; a separate mechanism should be provided for writing this data. Other mechanisms might include user-dened commands or write data transfers to a port reserved for module conguration. Although optional, it would be very valuable for an S-module manufacturer to implement a User-Specied Module ID code to further detail the modules identication by providing a means of electronically recording the currently installed software revision or possibly the installation date.
4Interested
applicants should contact the IEEE Standards Department, 445 Hoes Lane, Piscataway, NJ 08855-1331, USA.
21-9
IEEE Std 1149.5-1995
16 bits Packet 1 IEEE Std 802.3 code (lsw)
8 bits Packet 2 00000000
8 bits IEEE Std 802.3 code (msb)
Packet 3
16 bits User-specified Module ID code
Figure 21-4Packet formats for Module Manufacturer Identication port
21.8 User Identication ports (000E HEX 000F HEX)

21.8.1 Specications Rules (a) User ID ports shall support the Read Data command. (b) No User ID port shall support any Data Transfer class commands that alter the data accessible via that port.
NOTES 1Attempting to access the port having port identier 000E HEX 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 identier 000E HEX using any Data Transfer class command not supported by this port (21.2.1a) will cause the PTE bit in the Bus Error register to be set (11.8.1f). 2Packet latency in a Data Transfer class message selecting a User Identication port has to be documented (21.2.1b).
Recommendations (c) Packet latency for Data Transfer class messages selecting a User Identication port should be zero. (d) An S-module implementing an User ID port should provide a mechanism for writing the data accessible from that port.
21.8.2 Description
The User Identication ports, if implemented, may be used to access user-specic identication data. Examples of data that might be accessed include
21-10
IEEE Std 1149.5-1995
Data detailing specic 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 meansError/Status Shadow register port (0080 HEX)
21.9.1 Specications Rules (a) An Error/Status Shadow register port shall support the Read Data and Write Data commands.
NOTEAttempting to access the port having port identier 0080 HEX 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 identier 0080 HEX using any user-dened Data Transfer class command not supported by this port (21.2.1a) will cause the PTE bit in the Bus Error register to be set (11.8.1f).
(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.1.1d). (c) If backup means are provided for multiple S-module status registers in a given S-module that implements an Error/Status Shadow register port, (i) values in these backup means shall all be accessible in one Read Data message selecting that Error/Status Shadow register port;
(ii) interpretation of the data returned from that port in such a message shall be detailed in the Smodule manufacturers documentation; (iii) the data from the status register backup means transmitted in a Read Data message selecting the Error/Status 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 rst packet of this data shall be transmitted as the rst S-module transmitted packet in the port-specic part of a Read Data message selecting the Error/Status register port (17.1.1a; gure 17-1).
NOTEAs a consequence of 21.9.1c, packet latency will be zero packets in a Data Transfer class message selecting an Error/Status Shadow register port.
(d) If permission 21.9.1e 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 Read/Write Data command. 21.9.2 Description When a status register is read by the Read Status command, its contents are alteredin 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
ity. However, if for some reason a register has to be reread in such a situation, the original data would be lostif 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 dened 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.
21.10 Ports interfacing to IEEE Std 1149.1 boundary-scan (0010' HEX 001F' HEX)
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 interface 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 an 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 transport 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 dening common elements in methods of accessing an IEEE Std 1149.1 boundary-scan path via this Standard. Two specic 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 subclauses, we adopt the convention of calling the TAP controllers of selected scan paths selected TAP controllers. 21.10.1 Specications Rules (a) An IEEE Std 1149.1 Interface port (Port IDs 0010 HEX to 001F HEX) (i) shall provide access to an S-modules 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 Read/Write Data command; (iii) shall not support the Read Data and Write Data commands.
NOTES 1Attempting to access ports having port identiers 0010 HEX through 001F HEX 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 ports having port identiers 0010 HEX through 001F HEX using any other Data Transfer class command not supported by the selected port (21.2.1a) will cause the PTE bit in the Bus Error register to be set (11.8.1f). 2It may be useful to develop an application-specic non-destructive read command that extracts data from a scan chain while simultaneously feeding bits shifted out of TDO back into TDI.
21-12
IEEE Std 1149.5-1995
(b) At least port 0010 HEX shall provide access to an S-modules IEEE Std 1149.1 interface(s) using the Full TAP Control access method (21.11.1). (c) The port-specic part of the format for a Read/Write Data message selecting an IEEE Std 1149.1 Interface port shall be as dened in gure 21-5 and its embedded text.
NOTEDuring certain packet transfers at the beginning of the port-specic part of such a Read/Write message, the S-module may transmit either a NULL packet or a packet containing design specic data. For convenience, a new term is dened to described both options with a single symbol: An A.D.S. (Application-Dened 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 gure 21-5.
(d) The bits of a SELECT packet of a message selecting an IEEE Std 1149.1 Interface port shall be dened by table 21-2. (e) An addressed S-module shall interpret data of the BIT COUNT packet as dening the number of bits of data per test vector in the remainder of the current message.
NOTEA 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.1o) (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-IR) controller state; and, at this point, the signal on TCK shall be frozen.
NOTEThis function is expected to be used to scan out the contents of an IEEE Std 1149.1 boundaryscan data register immediately following the occurrence of some application-dened 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 SAMPLE/PRELOAD instruction to be scanned into the instruction registers of all devices on the scan chain to be subsequently selected by S.
(ii) The application-dened trigger mechanism shall become active when the S-modules SController enters its EOM Slave Controller state at the end of a trigger-setting message.
NOTEThe length of the message subsequent to such a SELECT packet is determined by the TAP control 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 specic 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-dened trigger event shall cause the TCK signal of the selected boundary-scan path(s) to resume activity as rapidly as possible.
NOTEThe 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 statein accord with the most recent trigger-setting action taken in compliance with 21.10.1.f(i).
21-13
IEEE Std 1149.5-1995
SELECT PACKET TMS/FUNCTION CODE PACKET
A.D.S. PACKET
Required packet pair transmission.
Required packet pair transmission A.D.S. PACKET except in messages governed by 21.10.1q and 21.11.1o.
A.D.S. PACKET
BIT COUNT PACKET
Packet pair transmission required if and only if test data is to be transmitted in current message. 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. Optional: Message may include 0 or more packet pairs of this type. Optional: Message may include 0 or more packet pairs of this type.
VECTOR COUNT PACKET
A.D.S. PACKET
DATA PACKET
NULL PACKET
DATA PACKET
DATA PACKET
NULL PACKET
DATA PACKET
An A.D.S. (Application-Defined Status) packet either 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-modules manufacturer.
Figure 21-5Port-specic part of read/write data message selecting an IEEE Std 1149.1 Interface port (g) If an S-module implements the Trigger on Event capability, the timing of events described in 21.10.1f shall be fully documented by the S-modules manufacturer. (h) If an S-module implements the Trigger on Event capability, (i) the means by which the user of an S-module may dene a trigger event (21.11.1j through 21.11.1n; table 21-3; 21.12.1g) shall be fully documented by the S-modules manufacturer;
(ii) the set of events that may be trigger events shall be fully documented by the S-modules manufacturer. (i) An addressed S-module (i) shall interpret the fourth packet of a Read/Write Data message selecting an IEEE Std 1149.1 Interface port as a VECTOR COUNT packet (gure 21-5) if and only if the MULTI bit (bit <13> of the SELECT packet of the current message was set;
NOTEOtherwise, the fourth packet pair transfer of such a message will be taken to be the rst DATA packet pair transfer.
(ii) shall interpret data of a VECTOR COUNT packet as dening the number of test vectors to be transmitted in the remainder of the current message.
NOTEA value of zero in a VECTOR COUNT packet effectively terminates test vector transmission (21.10.1j).
21-14
IEEE Std 1149.5-1995
(j) When an addressed S-module receives a BIT COUNT packet or a VECTOR COUNT packet containing 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.
NOTEReporting an error will have the effect of setting the PTE bit of the Bus Error register (11.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 (11.8.1b) if insufcient data are transferred to make up a complete test vector or set of test vectorsbased on the values in the BIT COUNT or VECTOR COUNT packet of the same message;
NOTEIt 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;
NOTEInability to execute such a function might be a result of its not being implemented in the given S-module.
(iii) all error conditions dened by 21.10.1k(i), 21.10.1k(ii) shall be fully documented by the Smodules manufacturer. (l) 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 signicant bit of the nth vector (1 < n < value in VECTOR COUNT packet) shall immediately follow the most signicant bit of the n-1th vector.
NOTETransmission of long bit strings is addressed in 5.5.1c, 5.7, and gure 5-6.
(m) Packet latency for all IEEE Std 1149.1 Interface ports shall be fully documented by the S-modules manufacturer. (n) The value 00000000 in the SLCT eld 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-modules manufacturer;
(ii) be interpreted as the identier (in the sense of table 21-2) of the single chain of 21.10.1n(i). Recommendations (o) A port interfacing to IEEE Std 1149.1 boundary-scan should support the Trigger on Event capability (21.10.1d; 21.10.1f through 21.10.1h).
21-15
IEEE Std 1149.5-1995
(p) On an S-module implementing a port interfacing to IEEE Std 1149.1 boundary-scan, one value of the SLCT eld of the SELECT packet should be dened that (i) causes the selected scan paths(s) TDI and TDO signals to be disconnected from all boundaryscan paths;
(ii) connects each selected scan paths TDI signal to that scan paths TDO signal.
NOTEImplementation of this recommendation would allow loopback testing of a port interfacing to IEEE Std 1149.1 boundary-scan.
Permissions (q) 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 Figure17-1 depicts the message format for a Data Transfer class message; and gure 21-5 denes the portspecic part of a Read/Write 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-specic 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 eld (bits<8..1>). The SELECT packet also identies which of two methods is to be used for accessing the selected scan path(s) (bit<16>). 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 TAPin the case of the FTC methodor an operation code identifying an operation to be performedin 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-modules 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 signicant bit (msb) rst so that lower priority S-modules participating in a Contend for Bus sequence (16.4.1) can detect when to cease participation. In contrast, the IEEE Std 1149.1 protocol requires that data be transmitted least signicant bit (lsb) rst. One important distinction is that the msb-rst 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 rst) into a holding register with MCLK as a clock, then unloading the register (lsb rst) feeding each selected scan paths TDI input with that scan paths TCK signal as the clock, and reversing the process for data returned from each selected paths 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 scan string) into appropriate MTM-Bus packets is specied by 5.5.1c.
21-16
IEEE Std 1149.5-1995
Table 21-2SELECT packet layout and semantics

Packet bit# bit<16> Abbrev. TMSB Meaning of bit value 1'The immediately following DATA packet shall be interpreted by an addressed S-module as containing TMS data as dened by implementation of the Full TAP Control access method (21.11). 0'The immediately following DATA packet shall be interpreted by an addressed S-module as containing a functional code dened by implementation of the Function-Based Control access method (21.12). bit<15> TLRB 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-modules S-Controller enters its PAUSE Slave Controller state following transmission of the SELECT packet; (ii) cause TMS of the selected boundary-scan path(s) to become asserted;
NOTEBecause TMS is frozen in the asserted state by requirement ii, no change of controller state of any TAP controller on the selected scan path(s) is possible (once the selected TAP controllers are in the Test-Logic-Reset controller state) until TMS becomes active again as a consequence 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. 0'An addressed S-module shall (i) cause TRST* of the selected boundary-scan path(s) to be released after the Smodules S-Controller enters its PAUSE Slave Controller state following transmission of the SELECT packet; (ii) cause TMS of the selected boundary-scan path(s) to be under control of the TMS/ FUNCTION CODE packet (should there be one) in the current message. bit<14> TRIGB 1'An IEEE Std 1149.1 Interface port implementing the Trigger on Event capability (21.10.1o) and being accessed by the FTC method shall enable (21.10.1f) that capability of the selected boundaryscan path(s) unless the MULTI bit is also set. In the latter case, the fact that the TRIGB bit is set shall have no effect on S-module functionshall neither enable nor disable the Trigger on Event capability. 0'An IEEE Std 1149.1 Interface port implementing the Trigger on Event capability (21.10.1o) and being accessed by the FTC method shall assure that that capability (21.10.1f) of the selected boundary-scan path(s) is disabled. The state of the TRIGB bit shall have no meaning to an S-module when an IEEE Std 1149.1 Interface port is being accessed by the FBC method. bit<13> MULTI 1'An S-module addressed by the FTC method shall interpret this value as meaning that subsequent DATA packets in the current message include data of more than one test vector (the number of vectors transmitted in the VECTOR COUNT packet (gure 21-5; 21.11.1f))unless the TRIGB bit is also set. In the latter case, the fact that the MULTI bit is set shall have no effect on S-module function shall be treated as though it were cleared. 0'An addressed S-module addressed by the FTC method shall interpret this value as meaning the remainder 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 port is being accessed by the FBC method. bit<12..9> RESV bit<8..1> SLCT Reserved for use in future versions of this Standard. An addressed S-module shall interpret this eld as an identier indicating which boundary-scan path(s) on that S-module is (are) to be selected. Moreover, such an S-module shall cause the identied path(s) to be selected.
NOTEIf bit<15> of a SELECT 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 state 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 1149.5-1995
Another important consideration when interfacing this Standard to IEEE Std 1149.1 is the relationship of the clocks. If the MTM-Bus MCLK signal is asynchronous with the IEEE Std 1149.1 TCK signal, then a mechanism has to be available for synchronizing the data ow 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-modules S-Controller is in its PAUSE Slave Controller state and the IEEE Std 1149.1 TAP controllers of the selected scan path(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 frequency than is the MCLK signal, then either the IEEE Std 1149.1 TAP controllers Pause-DR (Pause-IR) state may be used or the signal on TCK may be stopped after each DATA packets worth of input is shifted into the selected scan paths(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 dened 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 boundaryscan chain. The TLRB bit (bit<15>) 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 paths(s) modulelevel TCK input. The function supported by the TLRB bit is necessary in order to allow a coordinated reset of an S-modules IEEE Std 1149.1 scan path(s). The TRIGB bit (bit<14>) of the SELECT packet supports a trigger arming capability to be used to synchronize IEEE Std 1149.1 capture operation to occurrence of a specied 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.1g). If the TRIGB bit is set, data stored in the TMS/FUNCTION CODE packet are applied to the TMS signal and the signal on TCK is frozen just prior to the edge that would cause the selected TAP controllers to enter the Capture-DR controller state. The TCK signal is halted until a specied module event occurs. Upon detection of the event, the remaining data from the TMS/FUNCTION 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 eld (bits<16..9>) of the TMS/FUNCTION CODE packet represent the Pre-Trigger TMS data. The Post-Scan TMS Data eld (bits<8..1>) of that packet represent the Post-Trigger TMS data. The Pre- 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 bit<10> is transmitted on TMS; would go into the Capture-DR controller state as a consequence of transmission of bit<9> on the selected scan paths(s) TMS input were it not for the freezing of the selected scan paths(s) TCK signal. The Post-Trigger TMS data will always be a xed value (01000000) 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 instantaneous or non-instantaneous and may be predened by the manufacturer of an S-module or programmable through additional M-module transmitted DATA packets following the TMS/FUNCTION CODE packet. The event trigger function is of signicant importance when attempting to debug module operations by cap-
21-18
IEEE Std 1149.5-1995
turing data on the selected scan path(s) in coordination with a specic event (internal module condition, external signal, etc.). The MULTI bit (bit<13>) 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 DATA packets containing the serial test vectors. Note that all IEEE Std 1149.1 serial test vectors have to be of the same length.
21.11 IEEE Std 1149.1 Interface portsrequirements for the Full TAP Control (FTC) access method
21.11.1 Specications Rules (a) In a case of application of the Full TAP Control access method, the TMS/FUNCTION CODE packet shall have the format dened in gure 21-6.
PRE-SCAN TMS DATA bit numbers 16 10 9 8
POST-SCAN TMS DATA 2 1
Figure 21-6Format of TMS/FUNCTION 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.1c through 21.11.1f; 21.11.1i);
(ii) multi-vector transfer message (21.11.1g through 21.11.1i); (iii) a trigger setting message (21.10.1f through 21.10.1h; 21.10.1o; table 21-2; 21.11.1j through 21.11.1n); (iv) a trigger disarming message (table 21.2; 21.11.1o; 21.11.1p); (v) a reset message (a message in which the TLRB bit of the SELECT packet is setpreviously specied by 21.10.1d and table 21-2). (c) A single vector transfer FTC message shall be an instance of the message format dened in gure 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 <13>) shall not be set in the SELECT packet of the message;
21-19
IEEE Std 1149.5-1995
(iii) The message shall include precisely the number of M-module (S-module) transmitted nonNULL DATA packets necessary to transmit B bitswhere B is the value transmitted in the BIT COUNT packet of the message; (iv) The DATA packets specied by 21.11.1c(iii) shall 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 specied packet latency of such a message. (d) The bit string specied 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.
NOTETo 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, bits<16..13> of the SELECT packet have to be 1000.
(e) For each single vector transfer FTC message selecting IEEE Std 1149.1 Interface port, P, the following shall hold: (i) The message shall include data that shall cause transition of the selected TAP controllers from a given assumed starting controller state to either the Shift-DR or Shift-IR controller state.
(ii) The data satisfying 21.11.1e(i) shall be transmitted in the Pre-Scan TMS Data eld of the TMS/ FUNCTION CODE packet (gure 21-6) of the message. (iii) The 8-bit string satisfying 21.11.1e(i) and 21.11.1e(ii) 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). (iv) Subsequently, while the selected TAP controllers remain in the controller state determined in conformance with 21.11.1e(i) through 21.11.1e(iii), the function receiving data via the port P shall cause the bit string dened in 21.11.1c(iv) to be scanned into the TDI input of the selected scan path(s).
NOTEIt 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(s) due to the action of 21.11.1e(iii) will be held constant throughout the scanning process of 21.11.1e(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.1e(i) through 21.11.1e(iii) to a controller state in which the TAP controllers may remain indenitely 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 eld of the TMS/FUNCTION CODE packet (gure 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 specied in 21.11.1e(iv).
21-20
IEEE Std 1149.5-1995
(viii)Following the action specied in 21.11.1e(vii), the value of bit<1> of the Post-Scan TMS Data eld of the TMS/FUNCTION CODE packet (gure 21-6) shall be maintained on the TMS signal of the selected scan path(s) until altered by a subsequent Read/Write command selecting P. (f) A multi-vector transfer FTC message shall be an instance of the message format dened in gure 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 nonNULL DATA packets necessary to transmit the number of bits specied 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 specied 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 VECTOR COUNT packet. (v) The message shall include precisely the number of M-module (S-module) transmitted NULL packets equivalent to the manufacturer specied packet latency of such a message. (g) The bit string specied 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 consisting of V substrings composed of B bits each.
NOTETo 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 SELECT packet have to be 1001.
(h) For each multi-vector transfer FTC message selecting IEEE Std 1149.1 Interface port, M, the following 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 Shift-DR or Shift-IR controller state.
(ii) The data satisfying 21.11.1h(i) shall be transmitted in the Pre-Scan TMS Data eld of the TMS/ FUNCTION CODE packet (gure 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(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). (iv) Subsequently, the function receiving data via the port M shall cause the bit string dened 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
transitions taking the shortest path from the Shift-DR (Shift-IR) controller state reached per 21.11.1h(i) through 21.11.1h(iii) through the corresponding Update-DR (Update-IR) controller state and back to the Shift-DR (Shift-IR) controller state.
NOTES 1In 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 11100 to the TMS input between the scanning of any two serial test vectors. 2It is a consequence of 21.11.1h(i) through 21.11.1h(iv) that, while 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 specied 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 controller state in which the TAP controllers may remain indenitely 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 eld of the TMS/FUNCTION CODE packet (gure 21-6) of the message. (vii) The 8-bit string satisfying 21.11.1h(v) and 21.11.1h(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 consecutive cycles of the signal on the TCK input of the selected scan path(s) following the scan action specied in 21.11.1h(iv). (viii) Following the action specied in 21.11.1h(vii), the value of bit<1> of the Post-Scan TMS Data eld of the TMS/FUNCTION CODE packet (gure 21-6) shall be maintained on the TMS signal of the selected scan path(s) until altered by a subsequent Read/Write 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.1d, 21.11.1e(iv), 21.11.1f(iv), 21.11.1g, 21.11.1h(iv). (j) A trigger setting FTC message (21.10.1f through 21.10.1h; 21.10.1o) shall include only a SELECT packet and a TMS/FUNCTION CODE packet and those M-module transmitted DATA packets (if any) necessary to program the trigger function.
NOTETo 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 controllers (i) to make transition from an assumed starting controller state to the Capture-DR (-IR) controller state (21.10.1f(i));
21-22
IEEE Std 1149.5-1995
(ii) to do this in such a way that the rst 7 bits applied shall result in the selected TAP controllers being in the Select-DR(-IR)-Scan controller state.
NOTEAccording to 21.10.1f(i), the edge of the TCK signal that would cause the transition into the CaptureDR (-IR) controller state will not be transmitted to the selected scan path(s) until the defined trigger event occursthe TCK signal is frozen until the defined trigger event occurs.
(l) A trigger-setting FTC message shall include in the Post-Scan TMS Data eld of its TMS/ FUNCTION CODE packet the bit string 01000000.
NOTEThe post scan bit string required for TMS will leave the selected TAP controller in its Pause-DR (-IR) controller state. It is important that this be done; otherwise, a set of TAP controller state transitions including one into the Capture-DR (-IR) controller state will occur before it is possible to scan out data captured in response to the trigger event.
(m) The 8-bit string of the preceding rule (21.11.1l) 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 dened in 21.10.1f. (n) Following the action specied in 21.11.1m, the value of bit<1> of the Post-Scan TMS Data eld of the TMS/FUNCTION CODE packet shall be maintained on the TMS signal of the selected scan chain until altered by a subsequent Read/Write command selecting that scan chain. (o) A trigger-disarming FTC message shall include a SELECT packet transfer and no other subsequent packet transfer (gure 21-5).
NOTETo 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 cleared. In other words, bits<16..13> of the SELECT packet have to be 1000.
(p) An S-module function implementing the Trigger on Event capability and receiving a trigger disarming FTC message via an IEEE Std 1149.1 Interface port (i) shall begin the disarming process when that S-modules S-Controller enters its EOM Slave Controller state;
(ii) shall cause any trigger that is currently set to re; (iii) shall clear any bit in that S-modules status registers that would have been set if the trigger had been red due to the occurrence of a trigger event.
NOTEThe 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.11.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 paths 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 (gure 21-6). These two bit strings are of sufcient length to get from an original stable state in a TAP controller to the Shift-DR (Shift-IR) controller state before the (rst) test vector is scanned into TDI 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-Test/Idle, and Test-Logic-Reset. Holding a TAP controller in any
21-23
IEEE Std 1149.5-1995
other state requires stopping the signal on TCKhalting further IEEE Std 1149.1 boundary-scan operations.) The 8 bits of the bit string from the Pre-Scan TMS Data eld 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<16> 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<8..1> of the TMS/FUNCTION CODE packet are applied to the TMS signal as were bits<16..9>. The effect is the reversethe selected TAP controllers make a series of transitions beginning with the shifting state and terminating in a stable state. Bit<1> of the Post-Scan TMS Data eld 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 bitsmaintaining the selected TAP controllers in the desired, terminal stable state. Example: Assume that the selected TAP controllers have been left in its Test-Logic-Reset controller state at the end of the last Read/Write Data message selecting the port of interest. Also, assume that it is desirable to leave the TAP controllers in the Pause-DR controller state at the end of the planned test vector scanning sequence. For simplicity, we assume that only one scan path is selected. The TMS/FUNCTION CODE packet is set to F480HEXdening the TMS data necessary to create the desired state transitions. The BIT COUNT packet is set to 2AHEX, indicating the number of bits in the serial test vectors to be applied to TDI and captured from TDO during the message. Bits<16..9> in the TMS/FUNCTION CODE packet (1111 0100) cause the selected TAP controllers to make transition to its Shift-DR controller state (note padding in high order bits). While the selected TAP controllers remain in the Shift-DR controller state, 42 (2AHEX) bits of serial test vector data (transmitted in 3 DATA packets) are shifted into the selected module-level TDI input; and 42 bits of response data are captured from TDO output and transmitted to the M-module in 3 DATA packets. Bits<8..1> of the TMS/FUNCTION CODE packet (1000 0000) 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). 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
21-24
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 xed 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 0010HEX and is selected by setting the TMSB bit (bit<16>) of the SELECT packet. The FTC method may also be supported by MTM-Bus data transfer ports having port IDs in the range 0011HEX to 001FHEX.
21.12 IEEE Std 1149.1 Interface portsrequirements for the Function-Based Control (FBC) access method
21.12.1 Specications 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 specied in table 21-3. (b) The set of operations in the left-most column (Operation (operation code)) of table 21-3 shall be required of a port supporting the FBC method.
NOTEOperations are associated with a limited number of initial and terminal controller states [columns two (Initial controller state) and three (Terminal controller state) of table 21-3]. Hence, it is convenient to talk about a specic application of an operation in terms of a triple<operation, initial controller state, terminal controller state>. The sets of initial and terminal controller states of the individual operations are limited. When no action for a given operation is specified for the currently selected TAPs current controller state as initial state, the operation is not performed (21.12.1c).
(c) A function receiving/transmitting data via an IEEE Std 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 presently 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.
NOTEIf 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-Test/Idle instead of Pause-DR, execution of the <MASS PDR, Pause-DR, PauseDR> operation would result in the selected TAP controllers ending in the Run-Test/Idle controller state instead of the Pause-DR controller state. Worse, if the initial controller state were Run-Test/Idle instead of Pause-DR, execution of the <MASS RTI, Pause-DR, Run-Test/Idle> operation would end with the TAP controllers causing shifting of whatever might be on the selected scan paths 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-
21-25
IEEE Std 1149.5-1995
ments of the fth 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 TMS/FUNCTION 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 messages selecting an IEEE Std 1149.1 Interface port by the FBC method and having a message format that shall include only those packet pair transmissions depicted in gure 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 dened in gure 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 DATA packet transfers necessary to program the Trigger on Event capability.
NOTEThe 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 messages selecting an IEEE Std 1149.1 Interface port by the FBC method and having a message format that is an instance of that specied in gure 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 single vector transmission messages using the FTC access method (21.11.1c(i); 21.11.1c(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 interpreted precisely as in the case of single vector transmission using the FTC access method (21.11.c(iii) through 21.11.1c(v); 21.11.1d). (i) The UPDATE/SHIFT 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 specied in gure 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.1f(iii); 21.11.1f(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 method (21.11.1f(ii) through 21.11.1f(iv));
21-26
IEEE Std 1149.5-1995
(iii) The message shall provide for transmission of serial test data that shall be formatted and interpreted precisely as in the case of multi-vector transmission using the FTC access method (21.10.1l; 21.11.f(i) through 21.11.1f(v); 21.11.1g).
NOTEThe MULTI bit of the SELECT packet has no meaning in a message accessing an IEEE Std 1149.1 Interface port by the FBC method.
(j) 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 dened, that function shall cause the port to report an error. (k) 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 specied in gure 21-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-Test/Idle controller states in order for execution of a previously loaded boundary scan instruction to be completed.
NOTEIn table 21-3, the APPLY TEST operation is dened by means of a controller state sequence to bring the selected TAP controllers to their Run-Test/Idle 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 stateeither Pause-IR or Pause-DR. The integer value in the DATA packet dened in 21.12.1k(iii) species the time period in which the selected TAP controllers remain in their Run-Test/Idle controller states.
Permissions (l) Operation codes not required by an operation dened in table 21-3 may be used for user-dened operations.
NOTEFull documentation of such operations is required (22.1.1a).
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 IEEE Std 1149.1 Interface ports and can be specied for a given message selecting such a port by having the TMSB bit (bit<16>) of the SELECT packet of that message cleared. This method uses a set of primitive, predened operations to cause state transitions of the selected TAP controllers. The operation to be performed is specied through operation codes transmitted in the TMS/FUNCTION CODE packet (gure 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 denition. The FBC method focuses on cycling TAP controllers between stable states. A stable state is dened 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 dened for the FBC method controls movement between stable states of a TAP controller, 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
21-27
IEEE Std 1149.5-1995
from a given initial controller state to the Pause-DR controller state. A predened 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 (-IR) controller state to the corresponding Shift-DR (-IR) controller state and to begin shifting data. A SHIFT operation 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 captured 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 [Pause-DR (-IR)]. The state of the TRIGB bit of the SELECT packet of a given message is ignored if that message accesses an IEEE Std 1149.1 Interface port by the FBC 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 sufce: a) b) <MASS PAUSE-IR, initial controller state, Pause-IR> <SHIFT, Pause-IR, Pause-IR>
NOTEThe serial data to be shifted into the TDI input of the selected scan path(s) include the instruction code of the IEEE Std 1149.1 RUNBIST instruction in the appropriate position for loading into the instruction register of the target IC.
c)
<MASS RTI, Pause-IR, Run-Test/Idle>

NOTEExecute BIST.
d) e)
<MASS PDR, Run-Test/Idle, Pause-DR> <SHIFT, Pause-DR, Pause-DR>

NOTEScan out BIST results.
In addition to the operations described here, numerous user-dened 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 Smodule interface maintain current information regarding the controller state of all TAP controllers on an Smodule.
21-28
IEEE Std 1149.5-1995
Table 21-3Specication of operations for FBC access method of IEEE Std 1149.1 Interface port
Terminal controller state Test-LogicReset Run-Test/Idle Minimal sequence on TMS needed for transition 11111 110 0 Pause-DR 01010 111010 Exit2-DR (-IR), Update-DR (-IR), Run-Test/Idle Run-Test/Idle Run-Test/Idle, Select-DR-Scan, Capture-DR, Exit1-DR, Pause-DR Exit2-DR, Update-DR, Select-DRScan, Capture-DR, Exit1-DR, PauseDR Exit2-IR, Update-IR, Select-DR-Scan, Capture-DR, Exit1-DR, Pause-DR Select-DR-Scan, Capture-DR, Exit1DR, Pause-DR Run-Test/Idle, Select-DR-Scan, Select-IR-Scan, Capture-IR (-IR), Exit1IR (-IR), Pause-IR (-IR) Exit2-DR, Update-DR, Select-DRScan, Select-IR-Scan, Capture-IR, Exit1-IR, Pause-IR Exit2-IR, Update-IR, Select-DR-Scan, Select-IR-Scan, Capture-IR, Exit1-IR, Pause-IR Select-DR-Scan, Select-IR-Scan, Capture-IR, Exit1-IR, Pause-IR Fire the trigger Clear any bit in any status register that would cause an interrupt to be signaled indicating that the trigger event occurred. Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions
Operation (operation code) MASS TLR (0) MASS RTI (1)
Initial controller state any Pause-DR (-IR) Test-Logic-Reset
MASS PDR (10)
Test-Logic-Reset Pause-DR
Pause-IR Run-Test/Idle MASS PIR (11) Test-Logic-Reset Pause-IR
111010 1010 011010
Pause-DR
1111010
Pause-IR
1111010
Run-Test/Idle DISARM (1000) Trigger on Event capability armed TCK stopped selected TAP controllers ready to enter Capture-DR (-IR) controller state Pause-DR (-IR)
11010 Previously programmed when trigger was armed.
21-29
IEEE Std 1149.5-1995
Table 21-3Specication of operations for FBC access method of IEEE Std 1149.1 Interface port (Continued)
Terminal controller state Minimal sequence on TMS needed for transition Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions
Operation (operation code)
Initial controller state
For the following operations, two TMS sequences are required. These operations all have the characteristic that they invoke a controller 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 rst 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 Pause-DR 110 - 1010 First controller state sequence (CSS): Exit2-DR, Update-DR, RunTest/Idle Execute instructions previously shifted into IEEE Std 1149.1 instruction registers on selected scan path(s). Second CSS: Select-DR-Scan, Capture-DR, Exit1-DR, Pause-DR First CSS: Exit2-IR, Update-IR, Run-Test/Idle Execute instructions previously shifted into IEEE Std 1149.1 instruction registers on selected scan path(s). Second CSS: Select-DR-Scan, Select-IR-Scan, Capture-IR, Exit1-IR, Pause-IR First CSS: Exit2-DR, Shift-DR Shift serial test data into TDI input(s) of selected scan path(s) Second CSS: Exit1-DR, Pause-DR First CSS: Exit2-IR, Shift-IR Shift instruction into TDI input of selected scan path(s) Second CSS: Exit1-IR, Pause-IR
Pause-IR
Pause-IR
110 - 11010
SHIFT (101)
Pause-DR
Pause-DR
10 - 10
Pause-IR
Pause-IR
10 - 10
21-30
IEEE Std 1149.5-1995
Terminal controller state Pause-DR Minimal sequence on TMS needed for transition 10 - 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, nal controller state transition of rst CSS takes place: Capture-DR second CSS: Exit1-DR, Pause-DR First CSS: Exit2-DR, Update-DR, Select-DR-Scan Arm trigger and wait for trigger event If trigger event occurs, nal controller state transition of rst CSS takes place: Capture-DR Second CSS: Exit1-DR, Pause-DR First CSS: Exit2-IR, Update-IR, Select-DR-Scan Arm trigger and wait for trigger event If trigger event occurs, nal controller state transition of rst CSS takes place: Capture-DR Second CSS: Exit1-DR, Pause-DR
Operation (operation code) TRIGGER DR (110) These operations shall be the means of activating the Trigger on Event capability when accessing an IEEE Std 1149.1 Interface port with the FBC method. These operations shall have no effect if the selected port does not implement the Trigger on Event capability (21.10.1f through 21.10-1h; 21.10.1o; table 21-2).
Initial controller state Run-Test/Idle
Pause-DR
1110 - 10
Pause-IR
1110 - 10
21-31
IEEE Std 1149.5-1995
Terminal controller state Pause-IR Minimal sequence on TMS needed for transition 0110 - 10 Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions First CSS: Run-Test/Idle, Select-DRScan, Select-IR-Scan Arm trigger and wait for trigger event If trigger event occurs, nal controller state transition of rst CSS takes place: Capture-IR Second CSS: Exit1-IR, Pause-IR First CSS: Select-DR-Scan, SelectIR-Scan Arm trigger and wait for trigger event If trigger event occurs, nal controller state transition of rst CSS takes place: Capture-IR Second CSS: Exit1-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, nal controller state transition of rst CSS takes place: Capture-SR Second CSS: Exit1-SR, Pause-IR First CSS: Exit2-IR, Update-IR, Select-DR-Scan, Select-IR-Scan Arm trigger and wait for trigger event If trigger event occurs, nal controller state transition of rst CSS takes place: Capture-IR Second CSS: Exit1-IR, Pause-IR
Operation (operation code) TRIGGER IR (111) These operation shall be means of activating the Trigger on Event capability when accessing an IEEE Std 1149.1 Interface port with the FBC method. These operations shall have no effect if the selected port does not implement the Trigger on Event capability (21.10.1f through 21.10-1h; 21.10.1o; table 21-2).
Initial controller state Test-Logic-Reset
Run-Test/Idle
110 - 10
Pause-DR
11110 - 10
Pause-IR
11110 - 10
21-32
IEEE Std 1149.5-1995
Terminal controller state Pause-DR Minimal sequence on TMS needed for transition 11100 - 10 Required IEEE Std 1149.1 TAP controller state sequence and required coordinated actions First CSS: Exit2-DR, Update-DR, Select-DR-Scan, Capture-DR, ShiftDR Shift serial test data into TDI input of selected scan path(s) Second CSS: Exit2-DR, Pause-DR If last serial vector transmitted not yet scanned into selected scan path(s), repeat First CSS: Exit2-IR, Update-IR, Select-DR-Scan, Select-IR-Scan, Capture-IR, Shift-IR Shift instruction into TDI input of selected scan path(s) Second CSS: Exit2-IR, Pause-IR If last instruction transmitted not yet scanned into selected scan path(s), repeat None of these operation codes shall be assigned a function by users of this Standard.
Operation (operation code) UPDATE/SHIFT (1001) NOTEUPDATE/SHIFT is the only operation that supports a multiple vector transfer using FBC.
Initial controller state Pause-DR
Pause-IR
Pause-IR
111100 - 10
Reserved codes (1010 11111)
undened
undened
undened
21-33
IEEE Std 1149.5-1995
21-34
IEEE Std 1149.5-1995
22. MTM-Bus general documentation requirements

Documentation requirements for specic features are found in the text describing that feature. General requirements for documentation are located in this clause.
22.1 Documentation requirements

22.1.1 Specications Rules (a) Any Module or IC that claims conformance to this Standard shall document any implemented Recommendations or Permissions. (b) When implementation of a Recommendation or Permission requires the development of a user-programmable 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 commands (except as concerned with hazardous instructions mentioned in 22.1.1c) shall be fully documented. (e) For any S-module that claims conformance to this Standard, the data transfer ports implemented shall be fully documented and dened 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, minimum MCLK high time supported (t1), minimum MCLK low time supported (t0), and minimum sum of MCLK low and high times (t1 + t0).
(ii) Bus Error register: User-dened Error and Status bit denition, including the bits and associated transitions that cause the BSE bit in the Slave Status register to be set; timing of setting of BMR bit by any commands for which such detail is required. (iii) Module Status register: Error and Status bit denition, including the bits and associated transitions that cause the EVO bit in the Slave Status register to be set. (iv) Additional Status register(s): Error and Status bit denitions, 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 1149.5-1995
(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 Initialize Application command. (viii)Reset Module With SBIT command: Maximum time MTM-Bus will be off-line, Time required to execute. (ix) Reset Module Without SBIT command: Time required to execute. (x) Module Initiated Built-In Test (IBIT) command: Time required to execute, results of IBIT accessible through additional status registers. (xi) Disable Module I/O command: Disable values for ALL outputs, time required from command receipt to outputs disabled. (xii) Enable Module I/O 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 all implemented commands, when, in relation to the end of transfer of the HEADER packet or last packet of a message, a command conveyed by that message will begin and end execution. How the presence of errors affect execution of each implemented command.
22-2

IEEE 1149-5-1995 - Archived

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IEEE 1149-5-1995 - Archived

Încărcat de

Drepturi de autor:

Formate disponibile

IEEE Std 1149.

Test Technology Standards Committee of the IEEE Computer Society

IEEE Standards Board

The following persons were on the balloting committee:

Paula M. Kelty IEEE Standards Project Editor

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

1.2 The interconnection of modules with MTM-Bus

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995

Component Level Test Bus

Other Components Comp. Test Interface Boundary Scan

Subsystem Test Control

Figure 1-1Hierarchy of test and maintenance buses

1.3 Relationship to other test buses

1.4 Overview of MTM-Bus operation/protocol

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

Figure 1-2Translation between the MTM-Bus and on-module test buses

Figure 1-3 Backplane MTM-Bus signals

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995

MASTER MODULE PACKETS

SLAVE MODULE PACKETS

1st M-module DATA

1st S-module DATA

2nd M-module DATA

2nd S-module DATA

nth M-module DATA

nth S-module DATA

Figure 1-4Sample MTM-Bus message format

1.5 MTM-Bus protocol layers

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

Master Message Layer Master Link Layer Physical Layer

Slave Message Layer Slave Link Layer

1.6 Extensions to this Standard

on references can be found in 2.4.

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995

2. Conventions, denitions, and references

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

MTM-Bus Interface Logic

Module Application Logic

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995

IEEE Std 1149.5-1995

IEEE STANDARD FOR MODULE TEST AND

MAINTENANCE BUS (MTM-BUS) PROTOCOL

IEEE Std 1149.5-1995