ITC 2018 Invited Talk

Discuss the generic proposals for SJTAG
User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

ITC 2018 Invited Talk

Post by Ian McIntosh » Mon Aug 13, 2018 7:45 pm

Use this thread to propose and discuss ideas for material we can use for the STAM segment of the "New IEEE Standardization Efforts" presentation at ITC (and which we might re-use for NTF).
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Joel Irby
SJTAG Member
Posts: 5
Joined: Mon Sep 18, 2017 4:12 pm

Re: ITC 2018 Invited Talk

Post by Joel Irby » Sun Aug 19, 2018 8:04 pm

(first draft of ITC presentation; slides which illustrate problems to be solved by STAM IEEE standard aren't drawn yet)

Constructive criticism requested.... Feel free to download, add/modify/delete slides and send to me for review. Between now and the ITC talk on Tuesday 30 October, there will be a few "SJTAG Meeting" conference calls, so time-permitting, we can also discuss slide content during those.

http://files.sjtag.org/STAM_ITC18_v0_1.ppt

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Mon Aug 20, 2018 6:45 pm

I've copied this into the ITC2018 folder in the File Manager (to satisfy my file organisation OCD :wink: ) in both PPTX and PDF formats: It probably goes without saying that some illustrations are needed to add interest to this; we've probably got a lot ready made in various other slide packs that can be re-cycled - we just need to identify which ones might be helpful! I reckon we're looking for somewhere between 12 and 20 slides in total depending on content.

I note the comment in the slide notes about possibly adding an IEEE logo in the top left. The association with IEEE is probably implicit from the ITC logo already there so I don't think it's necessary (and it is probably questionable whether its use here would meet the criteria of "official business of the IEEE"). Instead, I'd suggest using the white versions of the SJTAG logo, either:

sjtag-logo-86x52-white.png
- http://files.sjtag.org/images/sjtag-log ... -white.png

- or -

sjtag-logo-165x100-white.png
- http://files.sjtag.org/images/sjtag-log ... -white.png

This leads on to a need, either in an introductory slide or a closing slide, to describe the relationship between STAM and SJTAG. People may have seen SJTAG mentioned at previous ITCs or elsewhere while STAM may be completely new to them. Probably also want to throw in the full title as it appears on the PAR at some point early in the presentation.

"Call to action" initially feels to me more like it should come towards the end, part of wrapping and telling folks what you expect from here on, but maybe it can also be used for "scene setting" early on. I'm not sure and will go with what others think.
You do not have the required permissions to view the files attached to this post.
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 110
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: ITC 2018 Invited Talk

Post by Bradford Van Treuren » Mon Aug 20, 2018 7:35 pm

I posted a revision with additional slides I was thinking of as the meat of the substance. It can be fetched from:
http://files.sjtag.org/Brad/STAM_ITC18_v0_1_BGVT.pptx
I also posted my Green Paper I wrote for the SJTAG Initiative Team Newsletter. It describes the 3 last slides I included:
http://files.sjtag.org/Brad/SJTAG%20Arc ... oncept.doc
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Fri Aug 24, 2018 6:45 pm

With regard to the additional slides that Brad added, I feel we ought to be cautious about using the term "SJTAG" on any of them (I realise that they were copied in verbatim from other packs) - slides 7, 11 and 12 in Brad's version. At the same time I'm unsure that "STAM" would be accurate in every case - which maybe reinforces the need to delineate STAM from SJTAG.

In terms of slide 7, I wonder if a better title would be "Illustrative STAM-capable System"? I'm sure I did an update to this diagram at some point, adding in a PMBus link - I'll look for it.

Slide 8 I recognise from Jeff Rearick's material - although a bit messy, I liked the way, on a variant of that slide, he overlaid views of where different standards applied (although I might disagree on some of his choices):
P1687.1_callback_approach_20170725.png
Slides 9 and 10 I think are good illustrations of the types of area that STAM needs to have rules/descriptions for, but I wonder if slide 11 is too "fussy" to be easily absorbed in a short session. The same might apply to 12.

[Edit] Here's the amended version of slide 7 I was thinking about: http://files.sjtag.org/ITC2018/Example_Diagram.pptx
Example_Diagram_700.jpg
You do not have the required permissions to view the files attached to this post.
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 110
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: ITC 2018 Invited Talk

Post by Bradford Van Treuren » Fri Aug 24, 2018 7:11 pm

I did look at Jeff's slide with the overlays that Ian shared. However, I felt it was going to be too busy for people to digest and was a bit cluttered to be able to clearly make out the structure of the interfaces. I too disagree with all the interpretations of the overlays. He is also missing the box at the board edge where SJTAG would take over at the system level. There are aspects of STAM in what is shown as SJTAG, but not completely until we fully define the STAM standard.

My feeling on the SJTAG vs. STAM is that we need to clearly present that STAM is a portion of SJTAG and SJTAG is not completely STAM. STAM is one of the building blocks for achieving SJTAG compliance.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Sun Aug 26, 2018 6:39 pm

I agree - I think Jeff's slide was a good idea but was probably incorrect in its perceptions of where SJTAG or STAM would apply. I'm thinking it be easier/better to come up with a relatively simple example of an application where STAM would be useful - not necessarily a solved example, but an illustration of the type of case we aim to solve. I have an idea in mind, so I'll try to diagram it, but may not have it in time for tomorrow's call.

On the STAM vs SJTAG question, I think its fine say that STAM is a subset of SJTAG, but it maybe will come across better if we could illustrate some topics that might also be considered SJTAG but are demonstrably not STAM? Foe example, I think one aspect is that STAM does not encompass the application layer.
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Mon Aug 27, 2018 8:40 am

Here's the example I was considering. Basically it involves JTAG, a bridge between JTAG and I2C and native I2C.
FRAM_Example.png
Here the FRAM memory is used to store information such as module ID, ETI and fault log data. In operation, the FRAM is powered from the system PSU and is interrogated and updated by the FPGA via the I2C bus, continually updating the ETI record and adding any BIT reports, etc. If the module is sitting on the shelf of a maintenance unit, a portable I2C reader can be attached to the test connector (and supplies power only to the FRAM) allowing the status of the unit to be queried without powering up the whole module.
There are lots of ways this kind of circuit could be tested, but one way might be to use JTAG, negotiating the path through the gateway to the FPGA and either initiating some test feature in the configured FPGA to write test data to the FRAM using its I2C master or by "bit-banging" the I2C bus using the boundary of an unconfigured FPGA and then using the external I2C master to validate the data, and then repeating the process in reverse using the external I2C master to write to the FRAM and validating it via the FPGA and JTAG.

Does this seem like a reasonable and suitably "accessible" example?
You do not have the required permissions to view the files attached to this post.
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 110
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: ITC 2018 Invited Talk

Post by Bradford Van Treuren » Mon Aug 27, 2018 1:54 pm

I guess my first reaction would be, "Why would you want to go through the JTAG interface to write to the FRAM when you have the I2C direct access from the system?" The answer would be to test the interface between the FPGA and FRAM, as you note. I would expect this would not be something used in the system for normal operation, but instead be a means of testing the interface assembly and operation in manufacturing to ensure it is assembled correctly and functions as expected with few functional tests (verifying pull ups are working correctly and not missing). I would think such a test would be implemented via a specialized downloadable Test Image for the FPGA instead of using bit-bang, however I have used bit-bang for such applications in a pinch.

This application is certainly an easy example to understand and shows the complexity of transformation between interface protocols required. Would this be an E-BIST of the FRAM type of instrument with total control of the test flow embedded in the FPGA and kicked off by JTAG or implemented as a JTAG to I2C-Master bridge where the top level application controls the sequences applied to the I2C bus through the JTAG interface, or a pure bit-bang test? It depends. The example allows for various scenarios to be discussed with a simple example application. It certainly exemplifies the possibilities of a multitude of implementation strategies applied uniquely to the same hardware.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Mon Aug 27, 2018 8:07 pm

On the SJTAG vs STAM question, in the meeting on February 26, 2018 I used this slide:

SG_Meeting_25.png
I don't, however, think it's a very good one: It shows that STAM lies within SJTAG but doesn't really help illustrate why STAM SJTAG or what other things might be SJTAG without being STAM. The "stack" idea seems more practical (or maybe a LEGO brick sort of idea with things on top of each other and side-by-side)
You do not have the required permissions to view the files attached to this post.
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Wed Aug 29, 2018 7:19 pm

OK, it's very embryonic, but this is more the kind of thing I had in mind when we talked about this on Monday. At this point, I really have little idea what would go in the other boxes or how many of them there are, so just threw in what came to mind for the purpose of illustration. One thing that bugs me though is that because PowerPoint's "Smart Art" for this is based on nested lists, it won't let me create a box at the bottom level that has multiple "parents" above it, so I had to put STAM in two boxes.
SJTAGvSTAM_v1.png
You do not have the required permissions to view the files attached to this post.
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 110
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: ITC 2018 Invited Talk

Post by Bradford Van Treuren » Wed Aug 29, 2018 8:35 pm

The problem I have with drawing these kinds of architectural stacks is you never really know how deep to draw. The reality is the STAM is dealing with two main aspects: modeling the system and coordinating/communicating with the HW resources interfacing to the top level protocol access link(s). So STAM is really sitting on top of possibly a JTAG Master, I2C Master, SPI Master, etc. These are probably applications or low level drivers understanding how to talk to the HW interface. These are really a layer above the OS and driver layer. It is really a function of the perspective when drawing such stacks. Never easy to get right. There will always be debate. STAM is going to be implemented more like middleware.

I was hoping we could draw a diagram something like this openstack diagram so we can use colored boxes to describe intent and show the dependency relationships, but I have to think about this more.
http://blog.naydenov.net/wp-content/upl ... ecture.png

I also was thinking of slide 5 in http://files.sjtag.org/BTW2014/Test_Man ... ollers.pdf, where the STAM block would fit in the bottom of the Test Step Controller between it an the different Control Systems as the coordination transformation the Test Step Controller is relying on to resolve how to implement the actions to be performed.

Slide 4 of http://files.sjtag.org/BTW2013/Design_P ... plates.pdf provides a little different perspective of the Test Step Controller. I see STAM modeling the various modules depicted for 1149.1, 1500, I2C, SPI, etc. that the Test Step Controller (inside SJTAG Test Manager cloud) is using to talk to the HW.

Back in http://files.sjtag.org/BTW2014/Test_Man ... ollers.pdf, slide 3 depicts the OSI type of stack I proposed in an earlier presentation http://files.sjtag.org/ITC2006/SJTAG-at-ITC2006.ppt, slides 31 and 32, to try to map the, then, current state of generated tests to a stack model to see if there are interfaces that could be defined. It broke down as I tried to deal with dynamic access applications in the embedded environment to control instrumentation on the fly. There are no pre-processed flows in that case that could be recalled as a prescripted test case.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Wed Sep 05, 2018 6:41 pm

I've been meaning to comment here for a few days and not been finding the time...

I think the type of diagram Brad is proposing would give a more accurate depiction of the relationships, assuming that we can identify the things we want to relate! However, I worry that it might become too difficult to absorb in the presentation format (better in a paper or article that people can read at leisure), but I guess it depends on what we have available to show.

On that topic, I'm reminded that one of the things we saw as "SJTAG but not STAM" was the hierarchical BIT reporting. This was something that could exploit STAM but didn't necessarily require it.

I'm in two minds about the applications or use cases (and maybe there's a subtle difference). Applications/use cases include all the things we've mentioned going way back to the original White Paper - Structural Test, Programming, Versioning, Root Cause Analysis, etc. Obviously you can do all of these without SJTAG so applications themselves could sit outside of SJTAG, but as use cases for SJTAG they remain in scope (this seems to be similar to what we're we're saying for the hierarchical BIT reporting).

Then there's the topic of system test metrics that Louis raised. This seems to sit alongside everything else: It could certainly inform people intending to use SJTAG, but that'd be true even if they weren't using SJTAG so it feels like it's entirely independent (rather in the manner that P2427 is decoupled from P1687.2).
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Sun Sep 09, 2018 7:40 pm

I'm sort of developing a thought here from my post above. It rather crosses over with the Defining SJTAG thread...

I'm beginning to feel that "SJTAG" might not be something that is definable within a standard or group of standards. STAM and perhaps the Hierarchical BIT Reporting (which is likely a protocol for communication between two hierarchical entities) are things for which conformance can be defined within a standard, but I'm feeling that SJTAG is more the bridge between these standards and the applications that use them. Perhaps the standards describe "what" and SJTAG encompasses the guide(s) to "how" (best practice recommendations?).

This seems to reconcile the Applications vs Use Cases dilemma for me but maybe presents a difficulty in diagramming as some things might exist both inside and outside the SJTAG domain (Applications overlap the SJTAG domain boundary but become Use Cases within that boundary while things like Hierarchical BIT Reporting could be used by Root Cause Analysis (say) either within the SJTAG domain or outside it (may or may not make use of STAM).
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Ian McIntosh
SJTAG Chair
Posts: 463
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: ITC 2018 Invited Talk

Post by Ian McIntosh » Fri Sep 21, 2018 7:21 pm

Regarding the updates to the EST Example diagram that was shared during the September 10 meeting, after discussing it a little with Brad, I have these two possible versions (both of which are in the mini-slide set I saved to the File Manager):

Layers_Slide_v1.PNG

Layers_Slide_v2.PNG
Version 2 adds an optional, but possibly unnecessary for this purpose, example of an independent application that doesn't rely on STAM but living side-by-side with STAM and accessing the same interfaces.
You do not have the required permissions to view the files attached to this post.
Ian McIntosh
Testability Lead
Leonardo UK