Print

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

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)

6. Any other business

7. Review new action items

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