I have been reviewing the IEEE 1149.5 standard to see if I could figure out where they went wrong with their concept and lack of acceptance. I believe it was far too hardware specific and locked people into a closed (as Michele puts it) architecture. SJTAG needs to be more open (as Michele also points out). However, there are some good strategies 1149.5 started out with in concept that may have just been misdirected due to a fact that it was hardware people trying to solve a mostly software problem. I will try to use the adornments in the Wiki, but be patient with me if I get things all messed up.
The IEEE 1149.5 SCOPE states:
This document standardizes a serial, backplane, test and maintenance bus (referred to herein as “MTM-Bus”), consisting of one or more logic boards, that can be used to integrate modules from different design teams or vendors into testable and maintainable subsystems. (In this document “board” is used in a broad sense to mean an assembled, usually field-replaceable, unit immediately above the device-level in a system’s assembly hierarchy—e.g., assembled printed wiring boards, assembled multichip modules, etc.)
The bus protocol defined in this document standardizes a method for communication of test and 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.
IMHO, it is the mandating of the MTM-Bus as the only means to communicate in the system killed off this standard. Well, at least the primary root cause of the lack of acceptance. Industry already had far too many communications busses in a system. There are now GigE, SPI, I2C, Multi-drop JTAG, etc. that all perform a specific purpose of transporting data from one location to another in the system. Each of them use their own protocol and hardware interfaces, that on the outside, looks to be very disjoint. If you attempt to abstract the purpose of each of these interfaces, you have to realize the simplicity of data is being sent to a destination target based on some hardware interface following a specific protocol managing the control of that hardware. Some of these interfaces have actually had further protocols overlaid on top of them. For example, I2C has SMBus and PMBus layered on top of the I2C protocol stipulating further restrictions of the bus' use. ATCA uses the IPMI layered on top of I2C. So there is an aspect of the Physical Layer (what we have been terming the HW interface) and various protocol layers built on top of the Physical Layer to define specifically how that Physical Layer is used. This is where IEEE 1149.5 was starting to get things right, but focused on the wrong Physical Layer as it was too closed of an interface based on current industry implementations of the day.
The Physical Layer
requirements specify the physical interconnections that comprise the bus. In 1149.5 they specified the physical interconnections, signal characteristics, and timing characteristics. That was too specific for SJTAG needs.
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.
This is corresponding more to what I have been terming as the Access Link. For SJTAG, we need to be able to support more than just one Physical Layer, but still keep the abstraction of the Link Layer standardized from a software interface perspective. This is similar to what the IP layer does for the ISO OSI model stack.
The Message Layer
requirements specify the syntax for messages and identifies the functions that have to or can be supported by the MTM-Bus Master or MTM-Bus Slaves.
This layer is really the heart of what SJTAG is going to be about. This is where I think we can get hung up on various turf wars if we are not careful. For example, it could be interpreted as defining how to send messages to an IEEE 1687 network. Or it could be interpreted as how to send a message to a specific Test Data Register in a device, that happens to reside on an IEEE 1687 network. It is at this layer where we have to be very careful at how we define our SJTAG architecture that will allow us to evolve over time. If we are too narrow with our scope at this layer, we become too closed. If we are too broad, we may never reach a consensus or diverge too much with child standards. What we have to think about is whether this layer needs to be further decomposed for SJTAG so we can build upon specific application needs: much like we have TCP and UDP for IP and the layers built on top of them for a networking analogy.
The other key take away in reading the IEEE 1149.5 standard is the definition of a 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.
The important aspect I see with PORT is that it is an abstraction to a register as well as to an interface for some other application. The problem I have with the 1149.5 ports is they are specific ports with defined addresses reserved for each of their purposes/functions. For SJTAG, a port is really an abstraction of a destination as defined by the underlying transportation protocol used (e.g., the Access Link). For SJTAG, the address may be a specific index offset and range in an overall scan chain. It may be a specific register of a device that has its own address defined through the Link Layer. It may be a specific Test Data Register selected by a specific Instruction Register in a device. It may be a message port to a piece of software running on a board as a service using a specific TCP/IP or UDP/IP listening port. SJTAG needs to be able to handle all these cases. It needs to define the classes of PORT addressing and manage their use in the model.
Where do we go from here? Obviously, we don't want to repeat the mistakes the 1149.5 working group made. We also need to narrow our scope for each release to ensure we can get something done in the time allotted. At a minimum, we need to define dot releases for the various Physical Layers we have identified to date and define how each Physical Layer ties in with the corresponding Link Layer above it as well as how the Link Layer ties in with layers above it. The dot1 draft needs to begin to carve out what we mean by the Message Layer or what we come up with as the replacement concept as the 1149.5 is a bit too narrow. In dot1 we can also begin to introduce the concept of the PORT and how it is an abstraction for the destination for the data message. What we have to figure out is whether a PORT's address is part of the Data Link managed by the model or by the Access Link. That can be complicated as some Access Links include the addressing as part of the selection protocol. Whereas, other interfaces don't explicitly require the addressing at the Access level (e.g., an offset and range in a scan chain). Personally, I think it can reside in the Data Link and referenced per packet by the Access Link for cases where the Access Link requires that information. Where we are differing from a network applications is the System Model resides in a single place in our world. We have not been distributing the management to each entity in all of our discussions. Perhaps that is good. Perhaps that is a bad assumption.
I hope this helps get us back on track to developing a direction to pursue. We need more people to comment on this forum. So please don't be shy.
You do not have the required permissions to view the files attached to this post.