Minutes of Weekly Meeting, 2017-01-18

Meeting called to order: 11:07 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Brad Van Treuren
Brian Erickson

By Proxy:
---

Excused:
Carl Walker
Peter Horwood
Heiko Ehrenberg
Bill Eklow
Adam Ley

2. Review and approve previous minutes:

  • Approval of January 11 minutes (updated draft circulated on 01/15/2017)
    • Brad had advised a typo correction and some additional text via email.
    • Insufficient attendees to vote on approval.

3. Review old action items

  • 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: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

a. Have we resolved what a "system" is?

  • Ian felt this hadn't been fully resolved during the previous meeting. Eric agreed. We seemed to be stuck between the "rack of cards" view or the "abstract description" view.  Brad thought it would be difficult to nail down a discrete definition. Ian could see Bill's point in arguing for the "rack of cards" as it would be a familiar notion for a lot of people, but also understood that other perspectives existed.
  • Brad used Google to try to find some common definitions of a system (URLs listed at the end of this section): The lead result was "a set of connected things or parts forming a complex whole, in particular". Ian remarked that there used to be a common definition that a system took some input, performed some operation of function on it and provided an output. Bred felt that the Tech Target view of "a collection of elements or components that are organized for a common purpose" was useful, particularly the "common purpose" aspect.
  • Ian agreed with the earlier view that "a system" was hard to define and might be polymorphic. Brian felt we needed a definition along with a couple of examples and considered that the "rack of cards" definition was be too limiting.  Ian noted that what we aimed to do wasn't restricted to a particular hardware level, but more acknowledging that there was some sort of hierarchy - this was what led to the "assembly of assemblies" concept, side-stepping the notion of a "system" altogether.
  • Brad believed we were looking at structural aspects versus behavioural aspects, making it impossible to delineate a single definition; it depended on context.
  • Ian proposed an action that everyone should look at the example definitions and try to compose some form of words that might capture what a "system" is, for discussion next week [ACTION].
  • URLS:

b. Do we need to think about what is "in and what is "out" of our "dot 0"?

  • Ian noted that "dynamics" (in the form of power management) had come up in last week's discussion with Brad suggesting we may need to take a step back and see if there are other dynamic aspects we need to consider.  Ian was broadening the question to ask if, from the recent requirements gathering or other work, we could list things that we'd decided ought to be in the initial standard or out of it. We had previously identified several things that we felt at that time were probably "extensions".
  • Rather than that, Brad felt there was a need to prioritise the requirements list, but was convinced it would be easy. Ian wondered if the whole exercise might be pre-emptive of work for the Study Group stage or actual standard preparation. Brad noted that for 1687.1, Al Crouch hadn't tried to prioritise requirements, but had put them into blocks according to how the related to his diagram. The Tiger Teams will now do any prioritisation.
  • Brad remarked that we don't have a clear diagram such as Al had. We are dealing more with "behaviour" which is harder to diagram. A better diagram for us would show the low-level building blocks - what standards we should be supporting in Dot0.
  • Ian referred to the "Illustrative SJTAG Infrastructure" diagram, agreeing that did not meet the need Brad described: What may be needed was almost a set of "X-Ray views" of segments of the diagram (to show the building blocks but removing duplicates from a particular example). We need to separate out what the actual low-level operations are from the Use Case(s) surrounding them. Brad felt that the original diagram was still helpful in defining the building blocks for a particular Use Case.
  • Brad referred to an email Michele had sent to the 1687.1 group on the parallel SIBs. In that he explains about looking at the behaviour - in that way, it is possible to ignore that it is a parallel SIB. We maybe need to think in terms of behavioural building block interfaces and we could probably take 1149.1 as a start. Ian agreed that 1149.1 was probably what a lot of people would be expecting to be a big part of a SJTAG standard.
  • Brad wondered if we needed something in our building blocks that required a Capture-Shift-Update flow. Ian thought that might be limiting but on the other hand, removing that constraint would make it harder to model.  However Ian thought that one of Michele's points had been that even where an interface does not strictly use the CSU cycle it may be possible to describe it as a combination of CSU cycles, even if it is a little inefficient. Brad remarked that this would depend on what the model expects.
  • One of Ian's concerns, when considering arbitrary interfaces is that, unlike an 1149.1 network, the response time may be non-deterministic, and there may be a need for some signalling to say that data is ready. Brad also commented, with reference to 1687 as an example, where there could be a buffer full condition that requires broadcasting to stop until there is space available. There may several requirements for "synchronisation".
  • Brad asked if these non-CSU interfaces needed to be modelled differently. Ian didn't think that was appealing. There was a question of how much was handled at the application level and how much was in the system model. If the system model operated at a low enough level then the application could deal with the synchronisation, but that would not aid portability. Brad agreed that portability, particularly moving a test from external control to embedded control, has been one of our long-standing aims.
  • Brad wondered if it was possible to model all building blocks simply through their access links. Ian suggested that if not, then we perhaps we simply decline to support those building blocks.

c. What are our next steps?: Study Group, approach to TTSC.

  • Brad observed that we had missed the window for getting to TTSC soon (it will be about three months before TTSC meets again) meaning it is too early to talk about Study Groups or PARs, so perhaps we should use that time to decompose down to the building blocks (answering Ian's earlier question about pre-empting Study Group work).
  • Ian agreed that it would be some time until we can officially engage TTSC, but as Adam (Ley) had suggested last week we can still approach Adam (Cron) to feel out the appetite for an SJTAG standard and what we ought to offer to TTSC, although that could be an "off-line" activity, while we continue with other work.
  • Brad suggested looking at 1149.1 and the different access conditions: Can we use just Read and Write as Michele had once proposed? CSU? Read and Write simultaneously? Perhaps Write before Read may be required in some cases? What buses accommodate CSU with Read only or Write only. Conditions become attributes.

6. Topic for next meeting

  • Definition of a system.
  • Building Blocks.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • None.
  • Carried over:
    • Definition of "interchangeability" required.
    • 'Instance' (or a more specific version of the term) may require definition in future.
    • 'Master through Slave Mode'
    • 'Master to Master Mode'
    • Need a refined definition of "system" for the purposes of the PAR.
    • 'Priority' - may relate to 'frequency' and 'urgency' in distinct definitions.

9. Schedule next meeting

  • Next meeting January 25.
  • February schedule:
    • 1, 8, 15, 22.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.
  • Ian has some material from Al Crouch on his proposal for "parallel SIBs". We may want to include him in one of our future calls to talk about this, but not at this time.

11. Review new action items

  • All - Propose a form of words to define "a system".

12. Adjourn

  • Eric moved to adjourn, seconded by Brad.
  • Meeting adjourned at 11:58 AM EST

Respectfully submitted,
Ian McIntosh