I'm going to attempt to capture the very useful discussion that happened in email in the last week. I'm basing the timeline purely on the order the messages are time-stamped in my email folder, starting with the earliest - that means some responses don't directly follow what they are replying to, but generally I think the thread is followable:
Louis wrote:In pursuit of reworking the legacy SJTAG definition " a system may be described as an organized collection of components or assemblies that are designed to operate together to perform one or more tasks or functions," I would like to comment that some of the functions are "synergistic" (only exist because of the combined contribution of two or more assemblies) but other functions are distinct irrespective of other assemblies in the system. The tests need to take this into account. One Design for Testability goal should be to allow each of the assemblies to be tested in that independent (isolated) manner.
Ian wrote:Indeed Louis, but at the risk of pedantry, the description of the lower level assembly (sub-assembly, board or whatever) would define the intended tasks or functions as only the set that can be provided by that level of assembly. So the definition seems to remain valid in the context of whatever you’re considering to be the testable item.
You’re certainly right that it is often the case that “the whole may be more than the sum of its parts”. That seems to lean towards “functional” test; in my experience, functional tests are generally very good at detecting the presence of a fault but not so good at diagnosing where it lies, unless the tests are very carefully designed and very focussed. And that generally requires that the testability is built-in from the bottom up (in my domain that means starting with the board designs) as trying to ask for more testability once something is built is a tough ask. So yes, the sub-assemblies need to be testable in their own right.
Louis wrote:If we are considering SJTAG (test) interfaces to be based on 1149.1 or 1687 then these mechanisms need to be able to help isolate assemblies from the system as a whole and should be eluded to in our definition of a system. A triangle is not merely a collection of 3 lines, but for testability and diagnosability we should be able to test each line for its properties without regards to the triangle. If all interfaces between the lines (corners and angle of the triangle) have the same testability properties (say, 1149.1 or 1687) then we should be able to accomplish that. I am suggesting that we say so in the definition.
So, actually I am not saying we should alter the properties of the definition that imply that “the whole may be more than the sum of its parts”. What I am trying to say, instead, is that the SJTAG definition should (in addition) encompass our desire to test the assemblies separately.
Terry wrote:It sounds like we are trying to describe a system in a way that guarantees that we will use 1149.1 and 1687 in the solution. My biggest concern is that doing so may limit the ability of whatever standard is eventually defined to be adopted. As we get further up the system hierarchy, the contribution of test programs based on scan chains is significantly reduced. Thus, requiring access be supported up at the highest levels becomes a cost/benefit question where test will often lose out.
In addition, we are trying to bridge a very tools-based testing environment (Chip and ICT board level testing), where pattern based testing is very common, with system level testing where functional testing rules the roost with it’s incumbent interdependency of software and hardware. In addition, we are bridging numerous vendor layers. It seems like if our group’s task is to document the need for a System Level Test Standard, then we must first find out what are the biggest headaches for system test folks. There are some on our committee who work in this field and that is a start. I would also wonder if we could get information from other large system designers to understand what types of problems they are seeing. Or perhaps get a survey of some sort going at conferences such as Autotestcon were there is a large proliferation of system test engineers. Once we have discovered and documented those problems, we can bin them to categories to outline the need. With that information, I think it would be the challenge of the standards committee to see if they can come up with a methodology that would meet those needs. Whether or not existing standards can be leveraged would have a lot to do with what the needs are.
All of this points to making sure that we are not trying to force the solution before we even justify the needs. I believe this means we should keep the definitions more generic and not add too much specific detail into them.
Naveen wrote:I agree. There are repository of past discussion and documents but need some real world problem schematics to look for solution and hence standards. Right now universe looks too big. The need here to write out those problem and looks for solution with standard.
Louis wrote:Great discussion...
Let's not forget that the name of the group is SJTAG, which implies - if it doesn't actually state - that we are trying to apply JTAG to system level test. Unless I am missing something, JTAG is 1149.1 and 1687 (and to lesser degree 1500, 1149.6, 1149.10 and even possibly SPI and I2C). So even if we can avoid these things in the definition of "system" they will pop up in the Scope and/or the Purpose.
I will let our Navy test experts chime in on this, Terry, but in chairing the Testability Panel at AUTOTESTCON for many years, I can tell you that System Level Test for that audience has always centered around being able to diagnose to the responsible replaceable subassembly.
I believe this is no different for other systems. A laptop manufacturer at Dell wants to know which assembly is causing a computer malfunction. When you at National put together an ATE and have a virtual instrument cobbled together from a power supply and a signal generator, you will want to know which one of those two is the culprit if the "system" is not working properly.
Perhaps the definition of the system can bypass the diagnostic issue, but wouldn't it be better to incorporate it there?
Terry wrote:Including the need for a diagnostic capability, yes, certainly that should be included. Trying to force 1149.1 and such all the way up to a system level is that real problem. For example, in my ATE case, I want to know if the power supply or the signal generator is the culprit. If both have provided some level of self-test that I can execute from the system level, that would be sufficient. I would not really care if I triggered this hypothetical self-test through a bscan method or by a special command through PXIe or GPIB. It would serve the purpose of the diagnostic task. That is my point. Let’s identify the behaviors that are needed and not try to define how they are executed.
Ian wrote:"Let's not forget that the name of the group is SJTAG, which implies - if it doesn't actually state - that we are trying to apply JTAG to system level test. Unless I am missing something, JTAG is 1149.1 and 1687 (and to lesser degree 1500, 1149.6, 1149.10 and even possibly SPI and I2C). So even if we can avoid these things in the definition of "system" they will pop up in the Scope and/or the Purpose."
In one word - No!
The title of the group is "System Test Access Management" specifically to get away from that 1149.1 centred mindset (and more pedantically, JTAG, as it was originally conceived, had a much broader consideration than just the serial digital databus that became 1149.1).
"SJTAG" is a convenient short form that ties in the legacy that the current study group grew out of, in much the same way that "JTAG" has stuck as a label.
Ian wrote:Louis, as I now understand your suggestion, you are proposing that a system, for our purposes, should provide means to isolate a sub-assembly from the other parts of the system in order that the sub-assembly might be better tested without interference from other sub-assemblies?
While that's a desirable property, I don't believe it can be a mandatory one. I'd argue that SJTAG could still be applied to a system that does not exhibit such a property, although what it could achieve might be reduced. This broaches on the notion that we could have "SJTAG compliant" and "SJTAG compatible" systems, where a "compatible" system may not have all the features desired for SJTAG but nevertheless supports its use.
Louis wrote:So let me understand:
Per Ian, this group "System Test Access Management" is in and SJTAG is out? So what "test access" mechanism are we considering here?
To Terry: Your approach to do self test of the instrument assemblies is fine, but still we need a way to communicate the results of those tests. 1149.1 or more likely 1687 is designed to be that test access. 1687 had the stated purpose to create hierarchical test information access from ICs to boards and from boards to systems as well as the other direction.
While I am surprised by these revelations of JTAG-less access, it does not change my original point that diagnosability is an important aspect of system level test and should be included in some form in the definition of a system or of a system test.
Ian wrote:I am not saying "JTAG-less", just not "JTAG only". The way we got here is that we recognised that, even if your intention is to perform an 1149.1 type of test, sometimes you need to interact with other interfaces to make that happen. That may be that you need to go outside of the 1149.1 protocols to operate a gateway, or use a parallel IO on some device to enable some part of a circuit or use I2C to make a path selection (I don't recall the details, but Brad had an example of, I think, a Brocade device that used I2C for 1149.1 path selection). If we're trying to organise tests at a level higher than the chip then we need to consider how we manage and coordinate the interfaces involved.
There's a parallel with 1687: I believe 1687 wanted to address more than just an 1149.1 external interface but fell foul of an overly specific statement of scope, hence 1687.1 being created to provide an extension for other serial buses.
Naveen wrote:In my understanding what we are looking for is:
“How to access and manage test (and/or diagnosis) from TOP to BOTTOM given the interface of hierarchical sub system (chip or board or …) which can be utilized (and/or proposed to support the modification required to ease system test and diagnosis)”.
It could be 1149.1 (which is one of interface standard and similar related 1687, 1500 down the level), I2C or SPI etc. The way to access and manage standalone chip is in place with these standard but what constraints and how to communicate and manage at upper system level looks challenge and looking for standard.
Louis wrote:OK - JTAG+.
Regardless of the means, I am convinced that we need the "system test" definition to include the necessity to diagnose unambiguously to a replaceable unit or if necessary, a limited number of replaceable units.
Ian wrote:OK, but a definition for "system test" is different from a definition for "system" - the latter makes no assumption about a use case, which is what the former is.
Ian wrote:I'd agree that is probably a fairly succinct evaluation of what we're aiming to do, Naveen.
Brad wrote:The definition of "system" should not contain the notion of diagnostics. System is a noun. I would agree that "system test" definition may include the notion of diagnostics, but it is not mandatory. SJTAG, as we are discussing it, is "System Test Access Management" as Ian pointed out. The key is "access management" in being able to obtain the information necessary to perform the diagnostics of a system. "System Test" is responsible for sorting through all the resultant data to determine a root cause as the diagnostics. SJTAG is an enabling technology that allows an application performing “system test” to be able to obtain the necessary information to conduct the diagnostic analysis. We are not trying to define a standard for a system tester. We ARE trying to define an enabling technology to allow a system tester to perform its function. So I would claim that SJTAG, based on this team’s title, is diagnostic agnostic in that SJTAG moves data through a system hierarchy, but it does not know for what purpose the data is used for. The data may be a snapshot of an internal state of an ASIC, it may be the result of an MBIST operation, it may be observed values of an interconnect test vector, etc. SJTAG really does not care. It is just responsible to get the data from point A to point B in a standardized, reproducible way. That is, in fact, the mission of 1149.1 and 1687 as well. However, both these standards have a way of preserving intent of the data by associating bit values with particular elements of the physical design (e.g, device pin, instrument register bit) via BSDL and ICL. That preservation is what we need to ensure is propagated back up the hierarchy so that an application at the top knows what part of the data represents the target bits at the leaves. The leveraged standards are responsible for mapping intent to bits at the leaves. SJTAG needs to have a means of preservation of location/position in the resulting data from all the transformations the data passes through in the hierarchy so an application may be able to reconstruct/deconstruct the data in the top level with the data actually at the leaves in order to perform the test/diagnostic functions. BUT this is only for interfaces bridging to these kinds of standards where this data is available. It is NOT a requirement on SJTAG to provide such information; only if the leveraged standard provides such information. Only the “System Test” knows what information is required to perform the diagnostic task at hand. This is why ATE systems today have various test applications in their arsenal that use an interface differently to obtain the data required to do it’s task (Infrastructure test app, interconnect test app, FPGA Programming app, FLASH programming app, MBIST app, SERDES BERT app, E-MBIST app, CLOCK FREQ Measure app, THERMAL Measure app, BIST app, Board-BIST app, SHELF-BIST app, TRANSMIT IQ Payload Out of Antenna app, STEER RADAR BEAM app, etc.). Depending on the task, the diagnostic knowledge is going to be different. The only thing in common is the infrastructure stimulating and obtaining results from the UUT. Thank you Terry for insisting we concentrate on the behavior of the interface. That will define what kind of information traversing the infrastructure of the UUT. SJTAG needs to be able to handle the data transfer necessary to perform these functions and to preserve important content intent of the leaf entities (this may be an instrument register, device BSR, Board-BIST status register, etc.).