Minutes of Weekly Meeting, 2012-09-17

Meeting called to order: 11:08 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Patrick Au
Peter Horwood (left 11:42)
Carl Walker
Brian Erickson
Heiko Ehrenberg
Brad Van Treuren (joined 11:08)
Adam Ley (joined 11:10, left 12:01)
Tim Pender (joined 11:14)

Harrison Miles

2. Review and approve previous minutes:

09/10/2012 minutes:

  • One correction noted: in 4b change 'CArl' to 'Carl'.
  • Brad moved to approve with the above noted amendment, seconded by Eric. No objections or abstentions.

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?
  • 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
  • Ian: Contact Bill Eklow regarding use of the ITC mailer to promote an SJTAG Fringe Meeting at ITC. - Ongoing
  • Ian: Make Use Case diagram accessible on the website prior to next meeting. - COMPLETE

4. Discussion Topics

  1. What are the functional primitives of our Use Cases? (see also forum thread: http://forums.sjtag.org/viewtopic.php?f=13&t=167)
    • This topic arose from last week's realization that our Use Cases really described applications, and contained overlaps and hierarchy that were not self-consistent. Considering that the topic may itself represent a significant task Brad suggested that it be worth considering this in terms of the registers that are used in each operation that might perform. The idea was that by looking at the logic of the TDRs we could assign some sense of what the vectors we communicate with those registers actually do and mean. For example, the Boundary Scan Register gives access to the I/O of the device, much like a general purpose I/O, while there are registers that hold static data such as the IDCODE or USERCODE and others that may have dynamic data such as the output of an ADC or temperature or voltage sensor. There may be instruments that are simply readable and others that may be writable. Ian wondered if this may lead to the low level 'read/write' type of statement that we warned against last week, but Brad hoped to stay at a level above that, and hoped it was a way to foster contributions from the group.
    • Ian observed that this was a bottom up approach while the thought from the previous meeting was more top down. Brad noted that it was common in the field of object oriented software to be faced with this decision, but he thought that the bottom up approach may be a more natural way for hardware familiar people to work. Heiko was unsure what he should be focussing on in order to contribute and felt this may not be a small enough target.
    • Ian wondered if there was a generic device model that we could explore; Brad felt that we may need to look at specific devices but proposed classifying devices into broad groups: Generic 'glue logic' like buffers and latches, representing the simplest BScan parts. FPGAs might be another; it may be unwise to use the broader programmable devices' as a class as there may be very different methods of programming in use. Tim noted that some Altera parts he is working with required both compliance pins and the JTAG pins during programming.
    • Ian proposed that listing registers would be a place to start, immediately identifying the BSR, IDCODE and USERCODE registers, while Brad referred to the standard for definitions, commenting that the instructions gave the semantics of what the TDR is trying to accomplish. The standard describes the BYPASS register in Section 10 and the BSR in Section 11, these being the two mandatory registers. Brad then quoted the description of the BSR from the standard. Ian observed that only part of the description could be accomplished by EXTEST, a mandatory instruction, while other parts of the description would require optional instructions, like INTEST, therefore it was impossible to define the primitive functionality purely in terms of either the register or the instruction and an amalgamation of the two was required.
    • Ian was concerned that this approach may lead to too many use cases that would need to be analyzed. Brad agreed that was possible, but felt that it may be something that we'd need to tackle at some point to be sure we cover everyone's needs.
    • {Peter left}
    • Ian wondered if this was something that needed some time to consider. Brad was hoping to identify some 'low hanging fruit' to break into the process but noted that he wasn't sure how we could describe the User Registers in an FPGA being used to program other devices, and asked if the others on the call had opinions on whether this was a useful path to pursue. Tim wanted to confirm that the intent here was to help analyze the Use Cases. Brad replied that the existing Use Cases are not written from a unified perspective and that we were trying to get to primitives that all exist on the same hierarchical level. Ian added that some of the existing Uses Cases actually employ other Use Cases meaning they were interlinked, and it would be preferable to get to independent descriptions that each stand alone from the others.
    • Heiko asked where we wanted this to take us. Brad's view was that he was looking for 'building blocks' that could be applied to different circuits and look for commonalities that could be exploited. Heiko wondered if the building blocks may be boards that are part of a system. Brad commented that this was about access to TDRs but also how that was useful; just being able to communicate with a TDR is useful for SJTAG in performing operations in the system.
    • Brad remarked that he also hoped to discover things that we aren't able to achieve, although evidence tends to suggest that people are usually able to find a way to work round any limitations.
    • Tim stated that he liked the idea of viewing the Use Cases from an application perspective, and considered that things like a power-on sequence may be different at an EMS that it would be in the system. Ian noted that this use of the word 'application' was different to that used earlier and may another case where we need to be careful in our definitions.
    • Brad wondered if two 'Tiger Teams' would be useful, one working top down and the other working bottom up. That way people could work with what they are comfortable. Brad sensed that Tim may be more comfortable working top down while Brad himself felt working bottom up was easier. Do both and meet in the middle. Carl felt that the normal way of solving a problem was to work top down until you found something to address and then work bottom up once you know that's required.
    • Brad wasn't sure how many people on the call were familiar with object oriented software design. Ian thought that may not be a relevant question as the issue was more about problem solving. Brad partly agreed and commented that ultimately it was about applying common sense.
    • Time had run out but this needed some further consideration. Ian asked that any thoughts on the matter, however loosely related to todays' discussion, should be posted on the forums (see action in section 8 for link) [ACTION].
    • {Adam left}

5. Key Takeaway for today's meeting

  1. Primitive functionality needs to be described with reference to an aggregation of both the register in use and the instruction applied.

6. Schedule next meeting

Next Meeting:
September 24 - Heiko and Eric will miss, Brad may miss.

October schedule:
1, 8, 15, 22, 29 - Eric will miss October 1, Brad will miss one Monday during October.

7. Any other business

  • The ballot is now open for the 1149.1 update. Heiko offered to act as a proxy if anyone who is not part of the ballot group had observations to make. Ian could do likewise.

8. Review new action items

9. Adjourn

Tim moved to adjourn at 12:10 PM EDT, seconded by Eric.

Respectfully submitted,
Ian McIntosh