[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-08-10

Call to Order:
10:35am EDT

1. Roll Call

Eric Cormack
Carl Walker
Brian Ericsson
Tim Pender
Peter Horwood
Adam Ley
Heiko Ehrenberg

Absences:
Ian McIntosh
Brad Van Treuren

2. Approval of August 3 minutes (draft sent 3rd August)

Corrections:
None

Mover:
Carl W.

Second:
Peter H.

Approved:
no objections or abstentions

3. Old Actions

  • 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
  • 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)
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
  • Ian/Brad: Construct new langauges/layers question(s) based on Brad's previous graphic to replace Q3.5. - Ongoing.
  • All: Test at least part of the draft survey form and provide comments through forums. - Ongoing.
    http://www.sjtag.org/survey/forms/form1.html
    http://forums.sjtag.org/viewtopic.php?f=32&t=83.
  • Ian: Revise wiki section on EST. - DONE!

4. Discussion Topics

  1. White Paper Review:
    • Review changes since last meeting.
    • [Ian by Proxy] I've revised the EST topic as we agreed, although I may still make some further changes between now and Monday. Some of last week's discussion on Embedded vs External test is really a Volume 3 subject. I have e-mailed Brad on this and he agrees that the main argument needs to be in Vol. 3, and the Use Case just needs to enumerate the advantages.
    • Continue Use Case discussion with Device Versioning
      http://wiki.sjtag.org/index.php?title=Volume_2#Device_Versioning
      http://forums.sjtag.org/viewtopic.php?f=14&t=52
    • [Brad by Proxy] The major points for device versioning are the ability to determine what vendor part is installed and what revision of that part is present. We had a case on an old system in the early days of system level JTAG where a second source part was assembled on some boards by the CM. Unfortunately, these parts did not have the hardware features that were expected in all cases and required a software patch to provide a work around. The only way we could identify what parts were installed in the field were to send someone there to do the upgrade and visually look at the boards, replace all field boards, or use JTAG to query the part (since it had IDCODE and was a BScan device, fortunately). We chose to use the latter to get an intelligent mapping of the install base to determine the best course of action. Some boards were behind firewalls so we had to send someone out for the upgrades anyway.
      The other aspect is the one regarding FPGA loads with the USERCODE. The USERCODE can give insights into what version of firmware is installed in the FPGA. This is especially useful when running INTEST tests on the device to validate the logic is working as expected. I would think Ian would find this useful as well. The USERCODE is used to determine dynamically what version of test to run.
      You should have a discussion regarding the automatic upgrades on FPGAs and CPLDs as well. How does a system realize the FPGA and CPLD programs are out of data/stale and need updating? There are many answers to this one and there are probably more solutions as well. Then there is the discussion we had previously about roll back if there was a failure. This is where Device Versioning overlaps the Programming use case.
    • [Ian by Proxy] Since you brought up USERCODE in your comments, I thought I should also throw in an observation here: USERCODE isn't mandatorily tied to firmware versions and it requires a conscious decision on the part of the person amending the firmware to also update the USERCODE, so it can go wrong procedurally. I'd also guess that some people may be using USERCODE for some esoteric in-house purpose - I can't actually think of a good reason here, maybe a date code or similar, but I'm just commenting on the possibility.
      We've tended to have larger FPGAs report version information over a debug port on boot up (often an RS485 that comes out of our system TAC), but CPLDs and smaller FPGAs probably get forgotten about. I'm pretty sure that JTAG accessible means, other than read-back and compare techniques, haven't really been considered that much.
    • [Peter] after reset the ID code register should be selected; so if you read that initially you get information out the chain configuration; need access to ID codes in a standard manner (consider different chain configurations);
    • {Adam joined}
    • [Heiko] in some cases you may have configurations of devices in the chain that look the same, but there are still differences on the board; some BScan devices don't have ID Register; non-BScan devices may be different; wiring may be different; FPGA/CPLD loads may be different; etc.
    • [Eric] boards may get identified via I2C devices; we would need BScan access/control over the I2C bus;
    • [Heiko] so, we can summarize this to "read ID Registers after resetting BScan circuitry, and/or provide standardized access to a I2C or SPI device to read board identification information"
    • [Tim] we use the USERCODE for firmware identification; you could put a serial number or checksum or similar information in there;
    • [Brian] Dallas Semiconductor has a device that can be preprogrammed with a serial number and then be read out; another option is MAC addresses;
    • [Tim] One-Wire EEPROM to store information;
    • [Brian] I think that is the Dallas device I was referring to;
    • [Tim] we need to make sure that all boards in a system can work together; so it is good to have all serial numbers and configuration information available for all sub systems;
    • [Tim] Altera CPLD, program USERCODE information, BSDL file that was created still does not include the USERCODE value information; -> may need manual modification of BSDL file;
    • [Tim] USERCODE may be forgotten to be updated; if different versions include the same USERCODE (because a designer forgets to update it) then the versions cannot be identified by the USERCODE;
       
    • Need to think about filling the remaining blanks from the earlier sections.

  2. 2009 Survey
    • Review comments received so far, e-mails or forum:
      http://forums.sjtag.org/viewtopic.php?p=217#p217
    • [Carl] I think the form was pretty self-explanatory.
    • [Eric] I'll submit the form this week
    • [Tim] I was about to submit something last week, when all the sudden my PC crashed; I'll have to fill out and submit the form again;
       
    • "To Do" items
    • Questions for 3.5 (per action)
      Brad probably hasn't had any time to think about this.
       
    • Questions on product value (see forum post:
      http://forums.sjtag.org/viewtopic.php?p=202#p202)
    • [Ian by Proxy] I think we need to get some measure of the scale or "value" of the products where people would see SJTAG being beneficial. Ties in to Value Proposition, but how do we measure?
    • [Eric] "Value" = money (Engineers may think of it as "time" but it comes down to "money")
    • [Ian by Proxy] "Value" will certainly equate to money, but what I was really getting at with this topic is that there may be several factors that might determine whether or not you think it's worthwhile investing in incorporating SJTAG into a system design. One factor might be the technical complexity; how easy is it to diagnose or fault find? Another is the unit cost, or selling price. A third might be the anticpated volume. Yet another may be the level of design reuse. You may be trading-off between these factors: A highly complex and expensive system might not carry an SJTAG justification if only a handful of systems are to be built, but that argument could be turned on it's head if the system actually re-uses boards from other designs. Or a low-value system might be able to justify SJTAG if the production run is expected to be hundreds or thousands.
       
    • Popup help boxes - Where are they needed? What help is required?
    • [Tim] a link to the White Paper may be useful for people who have not read it; Heiko: maybe a link could pop up if someone selects "No" as response to the question "Have you read the SJTAG White Paper?"; or the link could be included in the email solicitation to fill out the form

5. Schedule next meeting

August 17 Patrick, Heiko will miss
August 24 Heiko will miss
August 31 UK Bank Holiday: Will we have enough attendees to hold a meeting?
Should be OK as it will likely only affect Patrick, Eric and Peter.
Eric should be able to make 8/31; Peter will be out that day;

6. Any other business

the Newsletter, now that it is Quarterly, will be due at the end of the month we need topics at the next meeting.

  • [Heiko] all think about appropriate topics; perhaps we'll have the survey ready for then and we could announce it; or perhaps we want to start point people to the Wiki, perhaps section 1 and 2 are ready enough by then to be "published";

7. Review new action items

  • All: think about topics for upcoming SJTAG newsletter

8. Adjourn

Eric moves, seconded by Carl W.
adjourned at 11:25 am EDT

Heiko

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.