[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-02-16

Meeting called to order at 10:35 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Tim Pender
Heiko Ehrenberg
Carl Walker
Peter Horwood
Brad Van Treuren

Excused:
Patrick Au
Adam Ley

2. Review and approve previous minutes:

2/9/2009 minutes - Insufficient attendees to vote on approval. Those present had no corrections and none had been advised by e-mail.

3. Review old action items

  • Adam proposed we cover the following at the next meeting:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
  • Adam review ATCA standard document for FRU's states
  • Patrick contact Cadence for EDA support person.
  • All to consider what data items are missing from Data Elements diagram
  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient?
    see also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Adam: (continue) revise wording of section 5 - Ongoing
    • [Adam by e-mail] No progress to report.
  • Ian: Draft sample questionnaire by 02/09 - COMPLETE
  • Carl W./Andrew: Set up conference call to organise review of Vol. 3 - Ongoing
    • [Carl W] We had the meeting and I have some comments from Harrison, mainly around small form factor topologies and dot 7 enabled topologies.
    • [Brad] Can you explain "small form factor topologies"?
    • [Carl W] I understand it as just the way the bus is abstracted; I have a note from Harrison, but I haven't had time to take it in yet.
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
    • [Ian] I made some fairly minor additions: Some description of the UML and a little on the "discussion" page for Device Programming.
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Consider structure/content of survey - Ongoing
    • [Ian] I'm a little disappointed that there has been no feedback or comment on these two actions through either the wiki or the forum. The point of providing these was so that you can drop in and make observations as they come to you; you don't need to store things up for the weekly meeting.

4. Discussion Topics

  1. White Paper - Volume 4
    • [Tim] I'll confess I'm only just reading it now!
    • [Eric] It takes some reading and re-reading to take this in; there's a lot in there, some of which might take people by surprise, Java for instance.
    • [Ian] Yes, the one slight concern I had was that maybe there were too many languages mentioned in a relatively short piece of text.
    • [Eric] Well, they're relevant, and TCL is a very popular one right now.
    • [Ian] Certainly, TCL is a particular favourite of our hardware guys, in part because it's commonly used to script the build of FPGAs.
    • [Brad] You should also know that IJTAG are trying to standardize on TCL.
    • [Ian] I made an attempt at trying to flesh out some kind of description to go with the UML diagram.
    • [Brad] One of the discussions we need have is whether we need to have a scope down at the device level.
    • [Peter] It'd be nice, even in SVF, to be able to separate vectors into hex fields for individual devices. It would help debugging.
    • [Brad] But the padding in SVF would make difficulties there.
    • [Peter] It's more applicable for the data register.
    • [Brad] It may be for tooling to show this. Gunnar had classes and these could give you the data associated with each device, and we did something similar. Actually, a lot of detail is already there in the BSDL, but we throw it away when we go to the application.
    • [Brad] I think when we start analysing concurrency we'll find that we need to look at the register level, not the global level. In the UML, the SJTAG device is shown as the lowest level.
    • [Ian] So we need to expand below that?
    • [Brad] Yes, to take in the register set. It's part of the question of what needs to be in the standard versus what is in the detail of the implementation.
    • [Brad] There's a presentation I gave to IJTAG that maybe I should give here next week; it touches on how you do system test as well as taking care of the device instrumentation. {ACTION}
    • [Eric] You got some of that in your opening section where you mention IEEE 1500 and P1687.
    • [Brad] Yes, it's important that we stay aligned with all those other standards.
    • [Brad] I actually started to review 1149.5 to try to see where it went wrong. The sections relating to 1149.1 are 21.10, 21.11 and 21.12 which describe the boundary scan attributes.
    • [Brad] A lot of the things dot 5 tried to do were soon easier to do using I2C or similar. The main thing is that where dot 1 is a simple serial protocol, dot 5 is a packet based protocol. There are aspects that may be relevant for concurrent interaction aspects; we should investigate if there are things we can glean to help with our solution space.
    • [Ian] I'd just be worried that looking too hard at dot 5 will actually draw us into the same mistakes!
    • [Brad] That's why I'm being very careful to scope our interest to how data is carved up into packets. It's the complexity of the protocol that killed it.
    • [Heiko] Is the dot 5 standard still available?
    • [Ian] I think it's still available in IEEE website, it's just marked as "withdrawn".
    • [Adam by proxy] It appears to still be available for purchase in the IEEE Shop ({LINK HERE}); $118 for members.
    • [Brad] I just went to our "mirror". Maybe someone who can get access can pick out the main bits for an overview, maybe 3 or 4 slides? {no volunteers}
    • [Tim] On packetisation: Maybe you want to have a "Group ID" so, for example, you can gang program all the units with the same Group ID in one go. It would make the protocol more complex, though.
    • [Brad] But what do we want to support? At the top level, you could just command "do this test" or "test yourself and report the result". There's probably already a reporting mechanism for the functional test, so maybe you just use that? Where are you putting the autonomy? Then you get into the intelligent cluster we discussed last week; where is the domain of control or is it self-aware? So launching things in parallel opens a whole question of scope.
    • [Tim] It does seem to make sense to have more distributed control.
    • [Ian] I think you actually need to do both. Any form of embedded test control implies that some percentage of the circuitry needs to be functional for the test to run or report - a clock, processor, memory. This kind of goes against the original principle that JTAG can be run without presuming any functionality. So, if I get a box that won't run I still want to be able to go the old-fashioned way through an external 5-wire tap and test the unit.
    • [Brad] I have to agree. None of our products use embedded test to the exclusion of external test, for just those reasons.

  2. Survey
    • [Ian] We had a lot of useful discussion last week, and opened some new thoughts, but none of that has so far resulted in any tangible progress in preparing the survey.
    • [Ian] Last week Harrison commented that he saw the survey as two passes: The first being "level setting", while the second being a more focused set of questions based on the results of the first. I think I agree with that but at the same time I want to avoid the overhead of running two surveys in succession, so we need to find a way to combine the two passes.
    • [Ian] Peter also raised some fundamental questions on how serious people are about adopting SJTAG.
    • [Ian] I'm also keen not to have two many "career streams" for the detailed part of the survey. But is it enough to consider "technical" and "management" as sufficient granularity? Can we sort that out from the preamble questions?
    • [Brad] Well I have seen pushback from the technical side back to management where they've said they just could not do the job without JTAG. There's a case in point on microTCA where they used a Xilinx third party application for console debug output over JTAG since there just weren't any pins available to use another bus. So limiting some questions to just managers may be detrimental. (General-purpose Native jtAg Tester (GNAT) GNAT may be found at: http://www.xilinx.com/publications/xcellonline/xcell_53/xc_pdf/xc_jtag53.pdf)
    • [Eric] Are we considering the system design separately or just amongst the engineering side?
    • [Brad] The system architects?
    • [Eric] Yes, that's right; I often find that management pay more attention to the architects than they do to the engineers.
    • [Ian] I think we could offer questions that we don't necessarily expect everyone to answer. There will be different level of knowledge and awareness anyway, even if the streams were quite focused.
    • [Tim] As long as there's a get out: "Not applicable", "Don't know". I recently took a boundary scan survey and found that it was aimed at ASIC designers, so there a lot questions I had no idea about. That could get people supplying bogus answers and skewing the results.
    • [Ian] I fully expect that we'll need to offer some description of what we're trying to get at with each question, but at the same time trying to avoid leading the respondent in how they answer.
    • [Eric] I find that the architects generally have better understanding of all aspects than do the design engineers, DFT engineers, etc., that they might take input from.
    • [Brad] We need to know what we're trying to get from this.
    • [Eric] It's helping us to define our requirements.
    • [Ian] I think it's more defining our scope: Do we need to consider distributed systems as well as self-contained? How important are dot 4, dot 6, dot 7? If we get that then I think we already have a good idea of what the requirements are from the Use Cases.
    • [Ian] We need to sort out what is essential for our "dot 1" and what might form future extensions.
    • [Adam by proxy] I’m not familiar with this use of "dot 1" in this context. I take it as "dot 1" ≡ our first work product, whereas "future extensions" are subsequent work products. But, should it be construed that "dot 1" ≡ foundation/ framework, versus "future extensions" ≡ applications/ profiles? If so, I note that a foundation/ framework might be better denoted as "dot 0" (take the 1450 series, for example).

  3. Newsletter
    • [Ian] I've started to pull together the February newsletter, but I don't really have that much to put in it yet, so if there are any suggestions, I'd welcome them.
    • [Ian] I had an idea to open a "seed" on the forums to start a discussion on distributed systems, and reference it in the newsletter to try and spark some feedback and use of the forums by the SJTAG "fringe". Then maybe try and find another topic each month to treat in the same way.
    • [Brad] That seems like a good idea.
    • [Brad] Maybe we can throw out the UML diagram as a newsletter item linked to a forum topic?
    • [Ian] Yes, we could. I can embed the diagram in the HTML version of the newsletter. Maybe the bubble diagram version would be best?
    • [Brad] I'd say so. Do you need me to send you that?
    • [Ian] I've got it thanks, I used it at NTF.

5. Schedule next meeting

Monday Feb 23, 2009, 10:30 AM EST

Schedule for March 2009:
Monday Mar 2, 2009, 10:30 AM EST
Monday Mar 9, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar 16, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar 23, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar 30, 2009, 10:30 AM EDT (15:30 BST)
  • [Adam by proxy] It must be noted that EST will not be observed starting from Sun Mar 8, so the reference zone needs be changed (to EDT, GMT, or otherwise …). It also must be noted that Europe won’t be observing daylight saving time until our Mar 30 meeting date, so the Mar 9, Mar 16, and Mar 23 meetings will have a one hour offset from their usual times for either Europe or for USA

6. Any other business

  • [Brad] I'm finding that the SJTAG site is getting so big now that it's getting hard for me to find things; we have discussion on the wiki and discussions on the forums. Maybe, Ian, you could send out an e-mail giving links to the various forums for these discussions today?
  • [Ian] Yes I can certainly do that. {ACTION}
  • [Adam by proxy] Don’t forget that the site is also indexed for search. Local to sjtag.org, use the search tools at
    -- http://www.sjtag.org/searchsjtag/search.php, and
    -- http://forums.sjtag.org/search.php, and
    -- http://wiki.sjtag.org/index.php?title=Special:Search
    Also, the sjtag.org domain is indexed on Google, so Google site: search can be used, as follows:
    -- http://www.google.com/search?q=site:sjtag.org
  • [Ian] I realise there can be confusion over what the wiki is for and what the forums are for. In my mind the distinction is fairly straightforward: The wiki is for "Structured Documentation", the forums are more ad hoc debate that isn't directly tied to any specific piece of formal documentation.
  • [Ian] Within the wiki, each page has an associated "discussion" or "talk" page accessed by the "discussion" tab at the top of the page. You can use this to record suggestions or part-formed thoughts for the main article. The page editor can then delete off comments once they've been addressed and actioned.
  • [Brad] Ah! OK, that's a good use for that.
  • [Eric] And you've already linked the discussion pages back to the forum topic.
  • [Brad] Is there a way to be e-mailed when something changes?
  • [Ian] On the wiki, each article has a "watch" tab; if you click that the page (and it's "discussion" page) are added to your watchlist. Under "My Preferences" you can elect to be emailed if anything on your watchlist changes.
  • [Ian] On the forums, once you're viewing a topic, if you scroll right to the bottom you should see a "Watch this topic for replies" link at the left inside the grey box. That e-mails you when a new reply gets posted for that specific topic.
  • [Tim] I use the RSS from the forums. That works well - is there something similar for the wiki?
  • [Ian] I think so, just need to find it!
  • [Ian] For a general check, I use the "Recent changes" link in the left menu.
  • [Tim] Ah! There's RSS/Atom links here!
  • [Ian] OK. That makes sense - you get RSS from the Recent Changes page rather than individual articles.

7. Review new action items

  • Brad: Prepare presentation given to IJTAG for next week.
  • Ian: E-mail links to relevant discussion forums.

8. Adjourn

Moved to adjourn at 11:42 AM EST by Tim, seconded by Brad.

Thanks to Heiko for his notes, and to Adam for correcting my numerous typing errors!

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.